4.5 DATABASE

The hierarchical organization of the database allows mapping of the physical objects constituting the different hardware components into database structures (attributes, points, branches, classes) able to describe the logical relations existing between these elements.

The On Line Database Loader Manual [3] describes in great details how the database shall be designed, following object oriented principles. The reader is strongly encouraged to read this manual before designing any application. The following sections will simply highlight some aspects, or add some practical considerations.

Since most of the applications will be split between WS and LCUs, the database branches supporting them will also be distributed on both platforms. Nevertheless, they can be described in a single file. This feature, allowing a global and synthetic view of the database helps in the design phase, and later on, reduces the risk of errors during the implementation and maintenance phases.

4.5.2 Data Organisation

The modular structure used for code development applies also to data structures. Each individual module shall describe its own database branch. This branch should have a root point with name equal to the module name, the alias being the same, typed in lower case.

All applications shall refer to data in this branch, either relative to the module branch root point, by alias, or using direct addresses after resolution of a symbolic address following these rules.

· New classes specific to the module should be defined into modXXXX.class files stored in the dbl directory of the module.

· The module database branch should be described by declaring the necessary instances of the existing classes into xxxx.db files stored in the dbl directory of the module. On Workstations, the branch should be installed under the Appl_data point of the standard environment.

· The same database branch, extended if necessary with test points shall be used to build test environments to be defined in the test subdirectory of the module.

· Produce the complete database by including your xxxx.db files into the DATABASE.db file of your environment (make db). The environment is located in VLTDATA/ENVIRONMENT/<wsEnv>/<lcuEnv> for the workstation/ LCU.

· During integration, the dbl files from the different modules will be installed, and the global database created by attaching the module branches under the same root point.

4.5.3 Objects and Methods

Try to identify objects in your application, describe them as classes to produce a logical representation of them in the database.

Use the hierarchical capabilities of the database to map into the database structure the dependencies existing in the real world: if a motor has a tachometer, make the point representing the tachometer a child of the point representing the motor.

Put points and attributes representing signals where they logically belong to: motor temperature sensor as child of the motor, and analog input reading as attribute of the temperature sensor point. Use the hardware name of the signal as the alias name of the point to allow a flat view of all signals in your system.

CCS provide Object Oriented extensions with the eccs, evh and evhEt modules described in the section 4.6. Please refer to it and to the referenced user manuals for more details.

4.5.4 Database Access

Different addressing modes are available: symbolic hierarchical or alias, direct, lists. They are described in the CCS or LCC user manuals. Normal access should be symbolic hierarchical or with alias. The use of addresses relative to a current working point known by alias helps writing software independent of the real location of data in the database.

However, when performance comes to be an issue, it might pay to use one of the optimized access.

4.5.4.1 Direct addressing.

This first optimized mode uses the fact that the physical address (RAM, or disk) of an attribute can be resolved in a first step, and used at any time later on, provided it is still valid. The database is built in such a way that direct addresses within an environment keep their validity between startup and shutdown of the environment. A typical use of this feature is when an attribute is repeatedly accessed within a loop, and there are speed constraints. The symbolic address can be resolved before entering the loop, and the direct address used within the loop.

· This is interesting only for local attributes, since the time to resolve the address of an attribute is almost negligible with respect to the time spent in sending messages across the LAN to access remote attributes. Nevertheless, if repeated access to remote attributes is necessary, one should rather consider to use the scan system to maintain local copies of the remote attributes, and use direct addressing to access the local copies.

· Since applications are running within an environment, they should be stopped when the environment is shut-down, and restarted with the next startup. As a consequence, there is normally no need to monitor address validity within processes.

4.5.4.2 Use of lists.

This second mechanism allows to group several accesses in a single operation. This is particularly advantageous to access remote attributes. Since most of the time is spent on the network, merging all requests in a single message answered with a single reply is far more efficient than having one message and one reply for each request.

4.5.5 Event Handling

This mechanism allows to design event driven applications: A process can wait for a change of value of an attribute in the database to do something.

To achieve that, the process has first to register for event notification, indicating the attribute it is interested in, and then wait for a message notifying the change. Since the only official interface to processes is their Command Definition Table, this mechanism should not be used to request actions from processes. However, it can be used within a software module to coordinate several processes and efficiently share data.

4.5.6 Alarms

While the event notification allows applications to know when some value has changed in the database, the alarm system refines this mechanism.

It gives the possibility to define normal and abnormal values (discrete alarms) or ranges of values (analog alarms) for an attribute.

An alarm notification message is sent when the attribute value changes in the case of discrete alarms, or only when it crosses a range boundary for analog alarms. The alarm notification message is always sent to an alarm display, and to interested applications having subscribed for such a notification.

- Any alarm notification message is displayed on an alarm display, and automatically logged.

- An application using analog alarms doesn't have to check the attribute value against limits each time it changes in the database, this is done automatically by the alarm system, saving event notification messages, and coding in the application.

- An application interested in the general behavior of a "foreigner" system, doesn't have to know about exact addresses of attributes carrying this information. If alarms are used, the application just register for any alarm occurring in the database branch corresponding to that system. Such a registration requires only the knowledge of the root point of the corresponding database branch. All alarms produced by attributes located in that branch will be notified. Filters can be applied to avoid

notification of low severity or local alarms not really interesting an external application.

Alarms are defined in the database. Macro definitions are available for the dbLoader to define the different types of alarms: discrete or analog, with 2, 3, 4 or 5 states.

4.5.7 Database tables & C structures.

Since the database stores data as packed bytes, byte alignment between C structures and table records will probably not match.

If programmers find convenient to read (the same is applicable to write) a table record into an "equivalent" C structure, the data base should be carefully designed to accommodate these alignment problems. In particular if the code and the database must be portable across different platforms.

A typical example of such a database design can be found in the scan system. The scan output table of the device point can be directly mapped into a C structure. This is achieved, as one can see in the following declarations, by the introduction of unused padding attributes (named reserved 1 2 and 3) of the appropriate length to force the right alignment of the next attribute.

An alternative solution to this problem, is to have for every table in the database an equivalent C structure and two subroutines to pack and unpack the table record into the C-structure. From the point of view of portability this is the best solution. However the packing or unpacking associated to every individual access reduces performances and may become a problem when fast access is necessary.