|
|
Detailed description of the requirements
|
|
|
========================================
|
|
|
|
|
|
Sequences (scenarios) of interactions with the environment
|
|
|
----------------------------------------------------------
|
|
|
|
|
|
1. __System start__
|
|
|
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.
|
|
|
1. __Configuration__
|
|
|
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.
|
|
|
1. __Operating__
|
|
|
We have to distinguish two operating modes.
|
|
|
1. __Interactive__
|
|
|
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.
|
|
|
1. __Automated__
|
|
|
Controller actors are used to control other actors.
|
|
|
It must be possible to gain exclusive access to the controlled actors.
|
|
|
1. __Controller__
|
|
|
CS++ControllerActor is the base class for sequencer etc.
|
|
|
Derived classes implement the concrete controller.
|
|
|
1. __Settings__
|
|
|
It should be possible to switch between different sets of setting at runtime
|
|
|
and to store changed settings.
|
|
|
1. __System shutdown__
|
|
|
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_.
|
|
|
|
|
|
User goals
|
|
|
----------
|
|
|
|
|
|
### General
|
|
|
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.
|
|
|
|
|
|
### Base classes
|
|
|
__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.
|
|
|
|
|
|
### System configuration
|
|
|
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 handling
|
|
|
Error should be logged to the central message logger automatically.
|
|
|
|
|
|
1. 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.
|
|
|
1. 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.
|
|
|
|
|
|
### Actor Communication
|
|
|
1. Local
|
|
|
The NI Actor Framework provides local actor communication via queue.
|
|
|
1. Remote
|
|
|
Remote messages can be implemented using the
|
|
|
[Linked Network Actor](https://decibel.ni.com/content/docs/DOC-24051)
|
|
|
design pattern using network streams.
|
|
|
|
|
|
### Process variables
|
|
|
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.
|
|
|
|
|
|
### Hardware abstraction
|
|
|
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.
|
|
|
|
|
|
### GUI
|
|
|
Every actor can launch a corresponding GUI if specified either in the
|
|
|
configuration or programmatically.
|
|
|
|
|
|
### Mobile actors
|
|
|
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.
|
|
|
|
|
|
Functional requirements
|
|
|
-----------------------
|
|
|
### 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][AF]. Actors also behave as entities.
|
|
|
|
|
|
### Object Configuration
|
|
|
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.
|
|
|
### System Startup
|
|
|
Refer to User Goals:System start & shutdown.
|
|
|
|
|
|
### System Shutdown
|
|
|
Refer to User Goals:System start & shutdown.
|
|
|
|
|
|
### Message Logging
|
|
|
Refer to User Goals:Central message logging.
|
|
|
|
|
|
### Object Manager
|
|
|
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
|
|
|
------------------------------------------
|
|
|
### User interfaces
|
|
|
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.
|
|
|
|
|
|
1. __Main.vi__
|
|
|
_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.
|
|
|
![Launch CS++StartActor.vi](./LaunchCSPPStartActor.PNG "Launch CS++StartActor.vi")
|
|
|
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.
|
|
|
1. __CS++StartActorGUI__
|
|
|
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_.
|
|
|
![CS++StartActor](./CSPPStartActorGUI.PNG "CS++StartActorGUI")
|
|
|
|
|
|
### System interfaces
|
|
|
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.
|
|
|
|
|
|
1. __Data Socket__ Enables Data Socket communication and additionally PSP and OPC connectivity.
|
|
|
Refer to LabVIEW Data Socket help for details.
|
|
|
1. __Shared Variable__
|
|
|
1. _Standard SV_ Enables additionally PSP connectivity. Refer to LabVIEW Shared Variable help
|
|
|
for details.
|
|
|
1. _DSC - Data Logging & Supervisory Control Module_ It enables alarming and Trending on
|
|
|
shared variables. Refer to LabVIEW DSC help for details.
|
|
|
1. __DIM__ Refer to http://wiki.gsi.de/cgi-bin/view/CSframework/LVDimInterface for details.
|
|
|
Refer also to http://www.cern.ch/dim.
|
|
|
1. __OPC__ Connectivity to OPC can be provided via DSC-OPC-IO-Server. Refer to LabVIEW DSC help
|
|
|
for details.
|
|
|
1. __EPICS__ Connectivity to EPICS can be provided via DSC EPICS-IO-Server. Refer to LabVIEW DSC help
|
|
|
for details.
|
|
|
1. __FESA__ This is a low priority option for future use.
|
|
|
1. __BEL CORBA__ This is a low priority option for future use.
|
|
|
|
|
|
### Hardware abstraction
|
|
|
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.
|
|
|
|
|
|
1. __IVI instruments__
|
|
|
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.
|
|
|
1. __Motion drive__
|
|
|
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.
|
|
|
1. __Camera__
|
|
|
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](https://wiki.gsi.de/foswiki/bin/view/NIUser/HGFBaseClassLibrary). This class can probably be reused by changing the device base class in the inheritance tree and little modifications.
|
|
|
|
|
|
Other requirements
|
|
|
------------------
|
|
|
### Performance
|
|
|
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.
|
|
|
|
|
|
### Resources
|
|
|
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
|
|
|
Safety is not in our focus since personnel or device protection must be independent of this software framework and implemented in hardware.
|
|
|
|
|
|
### Portability
|
|
|
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.
|
|
|
|
|
|
### Maintenance
|
|
|
Since LabVIEW and the [Actor Framework][AF] 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.
|
|
|
|
|
|
### Reuse
|
|
|
The __CS++__ framework is designed to be reused for the development of real control systems, test-stands and automation applications.
|
|
|
|
|
|
### Usability
|
|
|
The __CS++__ framework is designed to be as simple as possible. Knowledge of LabVIEW, [Actor Framework][AF] and little about object oriented design patterns should be sufficient.
|
|
|
|
|
|
Client’s requirements for project management
|
|
|
--------------------------------------------
|
|
|
### Ready-to-use and bought-in components
|
|
|
|
|
|
1. LabVIEW Full Development Environment, Runtime Engine, NI Instrument Driver.
|
|
|
1. Optionally:
|
|
|
1. Data Logging & Supervisory Control
|
|
|
1. LabVIEW Realtime
|
|
|
1. Vision
|
|
|
1. Database Connectivity Toolset
|
|
|
|
|
|
### Subcontractors
|
|
|
CS++ will be developed in collaboration of interested people.
|
|
|
|
|
|
### Implementation requirements & Acceptance conditions
|
|
|
|
|
|
1. NI Style Guides have to be followed.
|
|
|
1. All sources should pass the VI-Analyzer to a certain degree (to be specified).
|
|
|
1. All packages should include examples illustrating the functionality of a set of classes.
|
|
|
1. EUPL has to be applied.
|
|
|
|
|
|
### Terms of delivery
|
|
|
|
|
|
1. Merge request to https://github.com/HB-GSI/CSPP or submodule repositories.
|
|
|
|
|
|
### Warranty
|
|
|
Refer to [EUPL](https://joinup.ec.europa.eu/software/page/eupl/licence-eupl). The license agreement is part of the distribution.
|
|
|
|
|
|
[AF]: https://decibel.ni.com/content/docs/DOC-17193 |