Detailed description of the requirements
Sequences (scenarios) of interactions with the environment
A Main.vi will parse the command line attributes and starts the CS++StartActor. All nested actors, at least the ApplicationMainGUI-Actor, are loaded as plugin via Factory and will be started from the CS++StartActor which provides also the option to shut down the complete system.
Object configuration data is provided in an ini-file by default. Objects can be created using a factory, that reads the configuration data and the objects will initialize their attributes from these data themselves. Derived factories can provide access to other storage media.
We have to distinguish two operating modes.
GUI-Actors provide access to controller and device actors. It should be possible to connect more than one GUI at the same time. It must be possible to gain exclusive access to the connected object.
Controller actors are used to control other actors. It must be possible to gain exclusive access to the controlled actors.
CS++ControllerActor is the base class for sequencer etc. Derived classes implement the concrete controller.
It should be possible to switch between different sets of setting at runtime and to store changed settings.
The running system can be stopped from the CS++StartActor. It will stop all nested actors and finally itself. The stop command can be triggered from the CS++StartActor or from the last acknowledge of the ApplicationMainGUI-Actor.
The aim is to provide a general framework for experiment control, test stands and other automation systems which serves as a base for the development of concrete applications. The development of these applications should be as easy as possible, which means more configuration than programming. The applications should use common and framework specific design patterns, which simplifies the development and maintenance even more.
CS++ should provide base classes to deal with objects as entities and actor(active processes). Objects of such classes have a name and can be created dynamically by using a factory, Initialization data is provided to the object as variant data, may be read from a configuration file. It must be possible to reference entities. Active object can have a corresponding GUI that becomes instantiated on request. More base classes provide behavior for devices and controller objects as well as communication.
Entity and actor initialization data is stored in sections of a ini-file. It contains the LabVIEW class and library path and other attribute values identified by LibraryName:ClassName.AttibuteName. Objects can share sections with common information, e.g. URLs of process variable published by a device and subscribed by a GUI. Command-line parameters specify which configuration to use, the name of the StartActor object and optionally the name of the factory to be used. The default factory reads initialization data from ini-file, derived factories can read from other media.
System start & shutdown
The Main.vi will read the command-line parameters and starts the specified StartActor, which will launch the MainApplicationGUI and optionally more (background) actors. All objects instantiated by the factory are reading their initialization data from the specified source.
The running system can be stopped from the CS++StartActor or the ApplicationMainGUI-Actor. All nested actors will be stopped. It should be possible to write changed attributes of entities and actors back to the system configuration.
Central message logging
CS++StartActor will maintain a connection to a central message logger. An abstract message logger will be used. Derived classes can implement specific message loggers, e.g. Syslog. Other classes can use the message logger to send messages to a central logger.
Error should be logged to the central message logger automatically.
- An actor stops executing by default in case of error. The derived actor class needs to override the Handle Error.vi in order to modify this behavior.
- The caller of a nested actor stops execution in case the nested actor stopped with error. The caller actor needs to override the Handle Last Ack Core.vi in order to modify this behavior.
The NI Actor Framework provides local actor communication via queue.
Remote messages can be implemented using the Linked Network Actor design pattern using network streams.
Different tiers should be coupled as loosely as possible. More than one actor should be able to monitor the status of another actor. Therefor every actor should publish its relevant status information to process variables. Other actors can use a (nested) process variable monitor actor to subscribe to PV changes.
Base classes and GUIs for several device types commonly used in the community will be provided. They inherit from CS++DeviceActor and derived classes implement the concrete communication with a specific device. Supported device types are: digital multi-meter, power supply, function generator, oscilloscope, analog input, analog output, digital input, digital output, counter, motion drive, camera
Control & Reservation
A controller object can have nested or aggregated controller or device actors. In order to perform its task undisturbed it should be possible to reserve them for exclusive access. A controller actor must have a chance to stop its task and release reservations in a controlled order if a task with higher priority requests reserved actors. Access to an actor means here: having access to its enqueuer.
Every actor can launch a corresponding GUI if specified either in the configuration or programmatically.
It should be possible to launch an actor on a remote system. This would be especially useful to distribute new software to remote systems for testing during development.
LabVIEW Objects as Entities
Since LabVIEW follows the dataflow paradigm LabVIEW Objects also follow the dataflow, which means objects become cloned at wire forks. It is necessary to provide methods to deal with LabVIEW Objects as entities. It is demanding to reference objects by name.
Active LabVIEW Objects
Since a control system, automation or test-stand has to deal with real world, objects need to be active to react asynchronous on changes of the environment or user interactions. Solution: Actor Framework. Actors also behave as entities.
Object to be treated as entities may need to become dynamically created and initialized using a factory. Configuration data is assumed to be stored in ini-file by default. Other storage media should be possible.
Refer to User Goals:System start & shutdown.
Refer to User Goals:System start & shutdown.
Refer to User Goals:Central message logging.
Objects used as entities need to be kept in memory. The Framework needs to ensure the object lifetime. Passive entities and actors must be treaded separately. Object Manager should maintain a list of distributed objects and actors.
External interfaces of the required system
We would appreciate if somebody could extend this document with hint to concrete GUI guidelines. At this moment we can think about two concrete GUIs. Default GUIs for the Hardware abstraction base classes need to be defined later. Most other GUI will be application specific. The requirements for those needed to be defined in the corresponding application requirements document.
Launch CS++StartActor.vi is provided to start the application which means that a CS++StartActor becomes launched. It can be called from the project specific Main.vi. This VI stops after launching the Start Actor. Parameters can be specified on the frontpanel or via command-line parameters.
The default values are:
- DB Connection String: ApplicationDirectory\ApplicationName.ini
- Start Actor: CS++StartActor
- CS++Factory: Empty String; default CS++Factory object will be used.
The frontpanel of the CS++StartActor has to provide at least the possibility to shut down the complete system. More features could be added. CS++StartActor should be invisible by default. The start actor will (de-)initialize the central message logger and start/stop a list of actors. The first actor in this list is considered to be the MainApplication-GUI.
Integration of hardware should be based on drivers provided by the LabVIEW environment or 3rd party, e.g. DAQmx, IMAQ, VISA, CAN, Profibus, OPC, DLL etc.
- Data Socket Enables Data Socket communication and additionally PSP and OPC connectivity. Refer to LabVIEW Data Socket help for details.
- Standard SV Enables additionally PSP connectivity. Refer to LabVIEW Shared Variable help for details.
- DSC - Data Logging & Supervisory Control Module It enables alarming and Trending on shared variables. Refer to LabVIEW DSC help for details.
- DIM Refer to http://wiki.gsi.de/cgi-bin/view/CSframework/LVDimInterface for details. Refer also to http://www.cern.ch/dim.
- OPC Connectivity to OPC can be provided via DSC-OPC-IO-Server. Refer to LabVIEW DSC help for details.
- EPICS Connectivity to EPICS can be provided via DSC EPICS-IO-Server. Refer to LabVIEW DSC help for details.
- FESA This is a low priority option for future use.
- BEL CORBA This is a low priority option for future use.
Device types commonly used in the community should be abstracted with base classes derived from CS++DeviceActor. Usage of such device base classes in the application enables easy exchange of devices of the same type but different models or different vendors by configuration.
The public interface of the base classes for digital multi-meters, power supplies, function generators, oscilloscopes and signal analyzer will be defined by the IVI driver subVIs.
The public interface of base class for motion needs to be defined by motion users. Karsten Open is willing to provide motion base classes and some concrete derived class implementations.
The interface of base class for cameras is defined by the NI-IMAQ and NI-IMAQdx driver subVIs. This has already been demonstrated within the HGF_IMAQ library. This class can probably be reused by changing the device base class in the inheritance tree and little modifications.
Since the CS++ framework provides basically base classes only little can be told about performance requirements of a concrete application. But, the CS++ developers should have performance issues in mind during development. A developer should follow the dataflow paradigm and make use of event driven communication between independent threads, polling should be avoided. He should care about memory allocation, especially when dealing with large data sets.
Refer to the resource requirements of the LabVIEW development and runtime environments. A concrete application maybe needs more resources.
###Security Potential applications in our focus do not really need security features. Different authorization levels simple password protection can be used to avoid accidental changes or user errors.
Safety is not in our focus since personnel or device protection must be independent of this software framework and implemented in hardware.
Since CS++ is based on LabVIEW it is portable to all platforms and operations systems supported by LabVIEW. This is maybe not true for application based on CS++ if they are using software packages that are not portable.
Since LabVIEW and the Actor Framework and many devices drivers are maintained by National Instruments only the classes’ part of this CS++ framework need to be maintained. Hopefully this framework will be adopted by the open source community. In this case the maintenance procedures need to be discussed with the community.
The CS++ framework is designed to be reused for the development of real control systems, test-stands and automation applications.
The CS++ framework is designed to be as simple as possible. Knowledge of LabVIEW, Actor Framework and little about object oriented design patterns should be sufficient.
Client’s requirements for project management
Ready-to-use and bought-in components
- LabVIEW Full Development Environment, Runtime Engine, NI Instrument Driver.
- Data Logging & Supervisory Control
- LabVIEW Realtime
- Database Connectivity Toolset
CS++ will be developed in collaboration of interested people.
Implementation requirements & Acceptance conditions
- NI Style Guides have to be followed.
- All sources should pass the VI-Analyzer to a certain degree (to be specified).
- All packages should include examples illustrating the functionality of a set of classes.
- EUPL has to be applied.
Terms of delivery
Refer to EUPL. The license agreement is part of the distribution.
CS++ Documentation von Holger Brand, Dennis Neidherr ist lizenziert unter einer Creative Commons Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.
Über diese Lizenz hinausgehende Erlaubnisse können Sie unter https://www.gsi.de/presse/ansprechpartner.htm erhalten.