libFAUDES

Sections

Types

Devices

The iodevice plug-in provides data-types that access hardware components to enable hardware-in-the-loop simulation, i.e. to run a supervisor on a physical plant . The devices implemented in this version of libFAUDES are motivated by LRT laboratory equipment, adaption to other hardware components should be straight forward.

Each device is configured by a libFAUDES token stream to map physical events (external events) to logic events (libFAUDES events). The prototypical example for a device is the SignalDevice, which interprets edges of electrical signals connected via a digital IO board as physical events. In general, devices distinguish between events that are triggered externally and events that are to be triggered internally. For the SignalDevice this amounts to sensor events which indicate edges sensed on a digital input signal and actuator events that impose edges on a digital output signal.

Devices also provide a clock referring to physical time. A simulator application may use this feature to synchronise the internal clocks of a timed automaton with physical time. The clock provided by a device refers to faudes time-units (ftu) since initialisation, where a scaling factor with unit ms/ftu is set at device configuration.

To inspect a libFAUDES device independently from the simulator, the tool iomonitor provides a simple command line interface to report sensor events and to trigger actuator events. There is also the iobridge to associate the respective events of two devices, which in conjunction with the SimplenetDevice can be used to implement PC based operator interfaces and/or process visualisation.

Technical Note: since hardware access typically depends on low-level libraries, individual devices must be explicitly enabled by compile-time switches in the Makefile libfaudes/plugins/iodevice/Makefile.plugin.

SignalDevice

Abstract interface for signal based event detection and execution.

A SignalDevice maps libFAUDES events (logical events) to edges on digital signals (physical events). It is an abstract data-type in that it does not implement actual hardware access. This is left to derived types, which in the standard libFAUDES distribution amounts to the ComediDevice.

Signals

Each individual signal is identified by an abstract bit-address which corresponds to a particular port/pin/connector of the underlying hardware. We assume all signals to exhibit a boolean range, i.e. at each instance on time the signal takes one of two values, referred to as high/low, active/passive or true/false. A signal may either be an input signal or an output signal depending on whether we can read or write its current value from the underlying hardware.

Input signals and sensor events

Each input signal is monitored periodically to detect edges. A sensor event is defined by its trigger sources given as a list of bit-addresses and edge polarities. Whenever a specified edge occurs, the simulator is notified about the occurrence of the respective event. The below fragment of a device configuration defines the logical event alpha to be triggered by either a positive edge (from low to high) on the signal with address 4 or a negative edge (from high to low) on signal 7. Note that, if both edges occur within one sampling period, only one event alpha will be issued.

"alpha"  
<Sensor>  
<Triggers> 
4 +posEdge+ 
7 +negEdge+ 
</Triggers> 
</Sensor>

Output signals and actuator events

An actuator event is defined by a list of actions that set or clear the value of a particular output signal specified by its bit-address. Whenever the simulator executes the respective event, the affected signal values are set accordingly. The below configuration example configures the logical event beta to set the signal with address 1 to low and to clear signal 8 to high.

"beta"  
<Actuator>  
<Actions> 
1 +Clr+ 
8 +Set+ 
</Actions> 
</Actuator>

Token IO

Configuration details depend on the supported hardware and are documented in the derived types, e.g. ComediDevice.

ComediDevice

Access digital IO hardware within the comedi framework.

A ComediDevice object is a SignalDevice that uses low-level drivers from the comedi-framework to access digital-I/O hardware. Available drivers include specialised PCI extension boards for automation as well as generic parallel I/O boards.

Low-level configuration

The comedi-framework provides a command line tool to configure the actual hardware that henceforth can be accessed via the system files /dev/comedi0, /dev/comedi1, /dev/comedi2, etc. Detailed instructions on supported hardware and the installation procedure are given on the comedi site. As an example, we provide a configuration script for the LRT laboratory PC equipped with two Advantech digital IO PCI boards:

#!/bin/sh
# Configure the comedi kernel module to run the LRT lab experiment.

echo 1. =========  load advantech module
/sbin/modprobe adv_pci_dio

echo 2. ========= setting up device 
comedi_config /dev/comedi0 -r
comedi_config /dev/comedi1 -r
comedi_config /dev/comedi0 pci1754 2,5
comedi_config /dev/comedi1 pci1752 2,9

echo 3. ========= running test 
comedi_test --device /dev/comedi0
comedi_test --device /dev/comedi1

echo 4 ========== report
comedi_info -f /dev/comedi0
comedi_info -f /dev/comedi1

See also ./libfaudes/plugins/iodevice/tutoral/data for a version of this script that cares about Linux user privileges.

Event-mapping configuration

ComediDevice objects inherit the event-mapping mechanism introduced by the SignalDevice. To configure the event-mapping you must supply the system device file, the sampling period for edge detection, and event definitions as described for the SignalDevice. The bit addresses 0 corresponds to the lsb of the first low-level data word and counts up to the number of available signals minus 1. An example configuration is given below.

Token IO

The example configures a ComediDevice to access the digital input port of the LRT lab Advantech PCI1754 via /dev/comedi0 and sense edges signal #4.

<ComediDevice> 
"LrtInputDevice" 	        	% device name 
500		    			% faudes timescale in ftu/ms
64                     			% max bitaddress 
100                		        % sample period in nsec 
"/dev/comedi0"     			% system device file 

<EventConfiguration> 
"alpha"  
<Sensor> <Triggers> 4 +posEdge+ </Triggers> </Sensor> 
"beta"  
<Sensor> <Triggers> 4 +negEdge+ </Triggers> </Sensor> 
</EventConfiguration> 

</ComediDevice>  

Note: this device must be explicitly enabled in the Makefile libfaudes/plugins/iodevice/Makefile.plugin

SimplenetDevice

Network based communication of events.

The SimplenetDevice sends and receives events in form of messages over a digital communication network. Together with the simulator plug-in, in can be used to implement decentralized supervision of discrete event systems. However, a very pragmatic approach is taken and the SimplenetDevice must not be confused with ongoing research that addresses synchronisation, real time behaviour, re-configuration, etc.

Network, Client, Server and Protocol

Network: A network is identified by its network name. A network consists of a number of nodes, each identified by its node name. Each node is aware of the entire network, i.e. the node names of all participating nodes. Each node implements both
1. a server to send event notifications and a
2. a client to receive event notifications.

Server: In its server role, the node sends event notifications whenever an actuator event is executed. The node is configured to listen on its server port for incoming network connections. It replies to a simple set command of commands to allow a connecting client to subscribe to the nodes actuator events.

Client: In its client role, the node receives event notifications for its sensor events. For each sensor event, there must exist some node, where the respective event is an actuator event. The client connects to all other nodes and subscribes to their actuator events. When it receives an event notification, this is interpreted as a sensor reading.

Protocol: The message protocol used for commands and notification is faudes-token based and uses the carriage-return ASCII code 0x0d to separate messages. Messages are sent and received over TCP connections. The message protocol can be inspected with the std network tools nc or telnet; see also the tutorial shell scripts. Protocol details are given in the IODevice C++ API documentation.

Token IO

For token IO, the SimplenetDevice reads and writes a section with label "SimplenetDevice". There are no relevant attributes yet. Simple machine example:

<SimplenetDevice>
"simplemachine"     % node name
1000                % time scale (ms/ftu)
"localhost:40000"   % server tcp port 
"simpleloop"        % network name

<Network>           
"simplemachine"     % other nodes ..,
"simplesupervisor"  % ... in this network
</Network>

<SimplenetEvents>
"alpha"  <Input></Input>
"beta"   <Output></Output>
"mue"    <Output></Output>
"lambda" <Input></Input>
</SimplenetEvents>

</SimplenetDevice>

Note: this device must be explicitly enabled in the Makefile libfaudes/plugins/iodevice/Makefile.plugin

libFAUDES 2.14g --- 2009-12-3 --- plugins "example synthesis observer diagnosis hiosys multitasking timed simulator iodevice luabindings"