how to build professional control system applications

How to Build Professional Control System Applications

Presented at the PCaPAC Workshop, 2000-10-09

G. Tkacik, M. PleskoJ. Stefan Institute

[email protected]://kgb.ijs.si/KGB

PCaPAC Workshop9.-12.10.2000

How to Build Professional Control System Applications, G. Tkacik 2

Client side CS design

Application framework

Applications

Device server

Hardware

Applications

Abeans

Device server

Hardware

Hide comm layer

Provide application services

Provide CS models

RAD, easier maintenance:



Analysis of ApplicationsPanelsRAD (no hand-written code)Short development cycle (days)



Panel Applications



Analysis of Applications

PanelsRAD (no hand-written code)Short development cycle (days)

Group ApplicationsControl of a large number of similar

devicesAggregate data for display



Group Applications



Analysis of ApplicationsPanels RAD (no hand-written code) Short development cycle (days)

Group Applications Control of a large number of similar devices Aggregate data for display

Complex Applications Monitor different devices, automatic or complex

response Technical requirements in addition to functionality:

synchronization, additional response processing...

Analysis of Applications



Abeans – The Where and The Why

NOW: Abeans Release 2Running in ANKAPrototypes for ESO and RIKEN completed

FUTURE: Abeans Release 3Design and implementation phaseANKA testing & deployment, porting

Thin vs. Full-featured dillemma (cost of flexibility)

Retain simplicity



Design Problems & Solutions

Components Functionality of Abeans basic building blocks

Containment Organization of Abeans basic building blocks

Plugs Making applications independent of the CS

communication protocol

Quality-of-Service Giving guarantees about the functionality offered

by the components



Containment – Motivation

Clues that point to the need for explicit containment Device beans contain Properties (e.g.

PowerSupplyBean contains current) Eliminate group code constructs like

for (int i = 0; i < devices.length; i++)devices[i].destroy();

Application contains its devices (“ownership”)

Parent – children relationship

: Use the containment tree



Containment – Problems

Multiple panels require multiple JVMs no memory

Control of a large amount of device beans (iterations)

Optimizations possible for large amount of device beans (packed monitoring)

Transparent containment and organization of programs

Life cycle management (when to create the framework, the order of creation and destruction)



Containment – Solution

Put all components into a tree (Composite pattern)Gain: Easy tree traversals (recurse) Independence of “virtual

applications” Apply Visitor pattern Unique string names of tree

nodes Well-defined startup /

shutdown order

:Root

:Framework:Plugs

:PSPanel:BPMTable

:PS1:BPM1 :BPM2



Containment – Result

Organization of Abeans into two parts Fixed (framework) – managers, loaders, services

Independent of CSs! Reusable application building framework Independent of the variable part

Variable – applications, device beans New nodes added / removed during RT Use framework services

Root

Framework

Variable part of the tree



Components – Motivation

Problems If you have a logging (configuration) library, how

do you change or modify it? If you have an application that uses authentication

mechanism, how do you make the mechanism available to all applications?

Design issues Modifying / extending framework functionality Solving framework thin vs. heavy dillemma



Components – ExampleLogging libraryLog.message(LOG_INFO,

“This is a message.”);

Direct access to the library

Cannot change the log functionality without changing the log implementation

Logging componentLogger log = (Logger)

cMgr.get(Logger.class);

log.message(LOG_INFO, “This is a message.”);

Access through component managers

Implementation can change as long as the interface remains the same

Application

Log library

Application

Log interface

Log implementation



Components – Solution

Create components: tree nodes with well-defined management accessible only through their interfaces

Identifiable

Node

Component

getComponentDescriptor()getState()initialize()suspend()resume()

Components allow you to change implementation, even at RT (state transfer)

Keep default implementations simple as placeholders for future (COTS) implementations



Components – Result

Existing components in R3 Logging, DataResourceService, ConfigurationService,

ReportService, DebugService, AuthenticationService, Loaders (file, URL, home dir)

Gain for application programmersUniform and prescribed way of adding new

functionality



Conclusion

VISION: As R2 separated plugs from beans, R3 will separate models (beans) from framework

Monolithic programming vs. framework + app programmer division of labour

Framework must pay off

how to build professional control system applications

Documents

abeans release

log functionality

partsfixed framework

tree composite patterngain

device beansnew nodes

length i devicesi

design issuesmodifying

analysis of applicationsabeans