Graeme Russ - 2007-12-01

Now that I'm back from holidays I can finally post my starting thoughts....

License Model
•    GPLv3 for all core components
Should we use LGPLv3 for the Device Driver API? To use the GPL would mean anyone wanting to create a device driver would have to release their source code. This is fine for protocols like Modbus, OPC, DNP3 etc, but not very attractive for developers of proprietary protocols.
•    What proportion of the SCADA market uses proprietary protocols which will prohibit the development of open-source drivers?
•    Could we reverse-engineer these protocols?
•    What if we implement the OPC client driver and any proprietary driver would have to use OPC? – Isn’t this defeating the purpose anyway?
•    What about two driver APIs - An Advanced released under the GPL and a Basic released under the LGPL? What would the difference between them be?
•    Do we take a stance as open-standards advocates?
•    Protocols like DNP3 have several existing proprietary implementations which would make implementing a driver using a LGPL library more attractive in the short term. However, I think we need to look at the bigger picture here.
Definitely leaning towards GPLv3 for the driver API

Data Security
It will be important at some stage to implement data security into the system including:
•    Per-user security at the object (and possibly sub-object) level
•    Client-Server encryption – encryption of the communications channel between server components and the clients (whether they be MMI clients, other server components etc)

Target Platforms
•    Can one SCADA platform suit all?
•    Can we create a modular architecture which would allow components to be included or excluded as needed for a particular platform?
•    How granular do we make the server? Do we split Configuration, Current Data,
Historical Data, Alarm & Events, and Drivers into separate processes that can be run on separate machines (or the same machine if desired)
•    If we split the server roles, can we create a code-base which will allow these roles to be aggregated into a single process to conserve resources for smaller systems?

Client-Server Model
The SOS Server will:
•    Manage the configuration database
•    Interface with I/O devices (PLCs etc)
Object Oriented

Server Roles
The following server roles are distinct entities which run as separate processes and may be run remotely using TCP/IP

Configuration Database
•    Online configuration changes
•    Hierarchical – Groups containing objects
o    Multiple hierarchy indexes (group by asset location, group by asset function etc)
•    Redundancy – multiple servers can synchronise the database ‘live’
•    Partitioning – sections of the database can be hosted on remote servers
•    Audit trail – All modifications are logged

Snapshot Database
•    Maintains all ‘Current Values’ for live data
•    All values area time-stamped
•    OPC-DA interface
•    OPC-XMLDA interface
•    ODBC interface

Historic Database
•    Maintains all historical trends and events
•    Reads per-point history configuration from the Configuration Database
•    Reads current values and time-stamps from the Snapshot Database
•    Performs storage optimisation (dead-bands, hysteresis, minimum logging interval etc)
•    OPC-HDA interface
•    ODBC interface

Alarms and Events Database
•    Maintains Alarms and Events
•    Reads per-point alarm and event configuration from the Configuration Database
•    Reads current values and time-stamps from the Snapshot Database
•    OPC-AE interface
•    ODBC interface
•    Consequential alarms
•    Alarm actions – When a given alarm occurs, do x
•   

Drivers
•    Interface to I/O Devices (PLCs, OPC Servers, RTUs etc)
•    Read configuration information from the Configuration Database and write values to the Snapshot Database
•    API for driver development. All drivers use the same API (no ‘built-in’ drivers)