Linux-Based PLC for Industrial Control
The mechanism employed by the gmm enforces semantics very similar to those in existing standard PLCs, but the two are not exactly the same. Situations arise where the exact same semantics are required, and this is resolved by the synchronization library. This library simplifies the task of the module programmer but leaves a lot of flexibility for the end user.
The synchronization library uses standard semaphores to synchronize the modules but does not make this apparent at its higher level interface. Module synchronization revolves around the concept of synchronization points. The end user can configure a PuffinPLC with a certain number of synchronization points (or synch points). The configuration data of synch points is loaded into the configuration memory upon PLC setup. Modules obtain handles to these points and then call a synchronization primitive to wait at a specified synch point. Having the module obtain the name of the synch point from the configuration file allows the end user complete flexibility in specifying the synchronization sequence for the application.
The end user must also define a petri net model (see Sidebar) of the sequence of events they wish to enforce. Synchronization points may be associated with the complete firing of a transition, the removal of tokens of a firing transition or the insertion of tokens of a firing transition. We also plan to support the association of synchronization points to the existence of a certain number of tokens in a place, the arrival of tokens in a place or the removal of tokens from a place, but some of these require more support from the operating system than is currently offered.
Modules waiting on a synchronization point associated with the firing of a transition will block until the transition is fired. Synchronization points associated with the insertion of places of a firing transition will never block, but they will insert the appropriate number of tokens into the places where a module synchronizes with this point. This, and the fact that the PuffinPLC will not fire a transition unless there is a module waiting on a synchronization point associated with that transition, implies that the semantics the PuffinPLC supports for the synchronization petri net are not exactly those of standard petri nets. But a modified petri net provides a base from which to work.
Using a petri net model allows very complex synchronization semantics. Nevertheless, due to the complexity of configuring this model, a simplified configuration syntax is also supported; it consists of a simple execution sequence for modules. This sequence is automatically transformed into its equivalent petri net model upon setup.
Every module is required to call plc_scan_beg() and plc_scan_end() before commencing and upon completion of its scan loop. These functions synchronize with two default synch points that, if not configured, will map to the null synch point that continues execution without delay. These two functions provide the hooks for the synch library to provide module synchronization in a standard form. Modules that wish to synchronize at other locations of execution can use additional synch points as desired.
The configuration library is a collection of functions that help parse the configuration file. The file is completely parsed upon module initialization and loaded into the module's heap memory. To obtain specific configuration data, the module calls functions that scan the parsed file from the heap memory. The configuration file may include other files using the *include directive. Circular includes are detected and supported.
The configuration file may contain name = value pairs or data organized in a table, for example:
table_name value_1_1 value_1_2 table_name value_2_1 table_name value_3_1 value_3_2 value_3_3
These values may be grouped into sections under the [section_name] syntax. Generally, the data required for PLC setup, such as plc points, synchronization points and model, are all placed under the [PLC] section. Other sections should contain the name of the module instance and the configuration data for that module.
The log library is a group of functions that provide common logging facilities for all PuffinPLC-related processes. Currently, nine logging levels are supported for error, warning and trace messages. These messages, with an additional timestamp, are placed into a logging file. We plan to offer the option of forwarding these messages to the syslog subsystem, taking advantage of the forwarding capabilities of TCP/IP to a remote message concentrator.
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
- Using tshark to Watch and Inspect Network Traffic
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development