Solution Decomposition

Revision A - 27 MARCH 1996

	Name	Position	E-mail address
Author(s):	Mats Grahm	Solution Team Member	pt93mg@pt.hk-r.se
Responsible:	Martin Puhv	Solution Team Manager	pt93mp@pt.hk-r.se
To:	SAIDA
Cc:

Abstract

As a starting point for estimation and design, we have identified the following components. Note that parts in this list does not necessarily belong to, or have a one-to-one correspondence with the interfaces or components mentioned in the top level "Requirement analysis" document.

1 Client Components

Remote Development Environment Client
Remote Data Navigator Client

2 CCN Components Developed by SAIDA

Remote Development Environment Server
Data Server
Logger
Alarm Handler
E-mail Handler
E-mail Command Interpreter
WWW interface

3 Other CCN Components

Parts of the system use standard components from NT Server, LCA and other sources. Only those who directly interact with SAIDA components are mentioned:

LCA Object Server
LCA Compiler Object
LNS Debug API
LNS Network API
WWW Server
Mail Server
Telnet Server
FTP Server

4 System Overview

Fig. 1. System overview.

5 Remote Development Environment Client (RDE Client)

5.1 Description

This is a client application that implements a GUI for editing, building, installing, and running NeuronC programs in the LAN. Its communication with the CCN is centralized to one CCN component, the RDE Server. It is still an open question how the client will be implemented, the alternatives are OLE Control and Java Applet.

5.2 Functional Requirements

Graphical Interface [Not Req.]
Implements through menus, buttons, and dialogue boxes all functions in:
- LCA compiler object [F16], [SAIDA 96]
- LNS debug interface [F20], [SAIDA 96]
- LNS network interface (message monitoring functions) [F13,F14], [SAIDA 96]
- Relevant methods in LCA object server [F17,F18], [SAIDA 96]
Editing of source code [Not req.]
Source debugging including [F20], [SAIDA 96]
- breakpoints
- single stepping
- watches
LAN message monitoring for selected messages and network variables [F13,F14], [SAIDA 96]

5.3 Functional Decomposition

The physical components needed to implement the functionality above includes:

Editor window
Debug window
System message output window
Network message monitor window
Menu bar
Approx. 5 - 10 dialogue boxes
Application logic and state machine
Communication hub

The communication hub is meant to serve as a centralized channel for all communication to/from the server. By isolating communication to one class, we make it easier to adapt to different communication solutions.

The Application logic and state machine is a central class that records what state the development environment currently is in, and what actions are currently available.

DISCLAIMER!

This is more of a wish-list than a commitment! In case of lacking resources, this sub-system is the one most likely to be limited to less functionality.

6 Remote Development Environment Server (RDE Server)

This is the CCN part of the RDE subsystem (RDE Client & RDE Server). It has only two main functions:

6.1 Functional Requirements

Provide a central point to which a client can communicate, regardless of which API it calls [Not req.]
Mirror some client state information that might be of importance to the server [Not req.]

6.2 Functional Decomposition

Client interface
State machine

To be able to estimate the size of the interface, relevant parts of LCA/LNS have to be examined closer. A short stub function will have to be implemented for most of the API functions. The size and complexity of the state machine is also hard to estimate until a more detailed design is completed. Hopefully the server can be constructed more or less stateless.

7 Data Server

7.1 Description

The Data Server is the central component for most interfaces, including the Data Navigator, Mail Command Interpreter, and HTML interface. It provides a framework for named variables that can be accessed in a uniform way, regardless of how the variable is implemented. Examples of variables that can be accessed through this mechanism includes LonWorks Network Variables, and SAIDA-implemented logs.< P>

Fig.2. Data Server framework.

Every variable handled by the Data Server have an external name, a type, and access functions for getting/setting it's current value. In addition, logged variables have access methods to allow access to most recent value, indexed access, value at a specific time, time for last change etc.

The Data Server maintains a hierarchy of external variable names, and maps get/set requests to the actual objects.

From the Data Navigator it should also be possible to create new variables, define their connections to network variables, create logs, set alarms, and navigate through the hierarchy. Functions should exist for this.

The type system should build on existing standards, possibly extended to allow the log types needed by SAIDA.

Finally, an event handler is needed to connect to LCA's event mechanism, and to allow other subsystems to be notified when, for instance, a value has changed.

7.2 Functional Requirements

Export named variables to external users [F1], [SAIDA 96]
Organize variables in a hierarchy [Not req.]
Allow creation/deletion of variables [Not req.]
Bind variables to some kind of value [Not req.]
Use existing type system [Not req.]
Allow creation/deletion of types [Not r eq.]
Provide by-name access to get/set functions [F2], [SAIDA 96]
Notify subsystems that have registered interest of variable changes [F38], [SAIDA 96]
Provide navigation primitives for moving in hierarchy and listing variables [Not req.]
Provide access to, and delegate calls to the Logger and Alarm Handler. This include:
- Create logs and setting their attributes [F36], [SAIDA 96]
- Create and list alarm conditions and actions [Not req.]

7.3 Functional Decomposition

Type DB
Value DB
Name DB
Variable Framework
- Generic Value superclass
- Logged Value subclass
- Network Variable subclass
- Type class
Basic Value Interface (get, set)
Basic Maintenance Interface (create, remove)
Navigation Interface (cd-, pwd-, ls-like functionality)
Glue to Logger Interface
Glue to Alarm Interface
Event Handler
LCA event glue

Besides these "physical" components, substantial design effort is needed for:

Name standard
Variable hierarchy structure
Type standard

The Data Server will probably be implemented as an OLE automation.

8 Logger

8.1 Description

This component is closely coupled to the Data Server, and will probably be implemented as a part of it. Requests to create logs and setting their attributes will be done via the Data Navigator client, which connects only to the Data Server. Log updates will frequently be triggered by the Data Server's Event Handler, something which also suggests implementation as one executable unit.

8.2 Functional Requirements

Allow creation/deletion of named logs [Not req.]
Allow connection to network variables [F36], [SAIDA 96]
Allow periodically polled and on-change-triggered updates [F38], [SAIDA 96]
Allow limitations in number of stored logged values and time limited store [Not req.]
Provide access methods for:
- Current value [Not req.]
- Absolute/Relative indexed access [Not req.]
- Value at a certain time [Not req.]
- Time for last change [Not req.]
- Min/max values [Not req.]

8.3 Functional Decomposition

Thread for time-based polled update
Thread for event-triggered update
Priority queue for scheduled periodical updates
Access Interface (get values)
Control Interface (create, delete, get/set attributes)

9 Alarm Handler

9.1 Description

Like the Logger, this component is closely coupled to the Data Server, and will probably be implemented as part of it. Also like the Logger, The Data Server provides the access path to the alarm control interface.

9.2 Functional Requirements

Allow creation/deletion of a named alarm
Allow definition of alarm conditions, actions, and priorities
Implement an e-mail action
Provide a hook where other actions could later easily be added

9.3 Functional Decomposition

Thread for time-based polled alarms [F35?], [SAIDA 96]
Thread for event-triggered alarms [F35?], [SAIDA 96]
Control interface (create, delete, set conditions and actions) [F35?], [SAIDA 96]
Condition expression evaluator [F35?], [SAIDA 96]
E-mail output function [F35?], [SAIDA 96]

10 Remote Data Navigator Client

10.1 Description

This is a client application that implements the user interface for the Data Server, Logger and Alarm Handler components. It will be implemented as an OLE control, or possibly a Java Applet.

The main function is to list the expandible/collapsable variable hierarchy in a window, and instances of variables in another. From this window it should be possible to connect an OLE representation of the variable to any standard application which complies to OLE.

Beside this main function, the user should also have access to functions to list, create, delete and manipulate variables, logs and alarms as described in resp. sections above.

10.2 Functional Requirements

Implement the GUI for listed functions of the Data Server, Logger, and Alarm Handler [Not req.]
Allow OLE connections to any OLE-aware standard application [F1], [SAIDA 96]

10.3 Functional Decomposition

Window for variable hierarchy
Window for variable instances
List box/Dialogue box for Logger functions
List box/Dialogue box for Alarm functions
Menu bar
"Object Factory" for OLE-objects representing SAIDA variables
Application logic and state machine
Communication hub

11 E-mail Handler

11.1 Description

The Email Handler serves as glue between SAIDA and an existing mail server. For communication with SAIDA subsystems and Neuron nodes, a data type "mail" is defined with the Data Server. Variables of this type can be implemented as a network variable bound to a Neuron node.

An address database connects e-mail addresses to SAIDA variables. Incoming mails are copied to the right e-mail variable. Outgoing mails are forwarded to the mail server unless their addresses shows that their destination is within the system.

A special e-mail address is assigned to the E-mail Command Interpreter, described below.

11.2 Functional Requirements

Allow connection of e-mail addresses to SAIDA e-mail variables [F6,F7], [SAIDA 96]
Copy incoming e-mails to correct destinations [F6,F7], [SAIDA 96]
Send outgoing e-mails to existing mail server [F6,F7], [SAIDA 96]

11.3 Functional Decomposition

Address DB
Thread for incoming mail (polling mail server periodically)
Thread for outgoing mail
Priority queue for outgoing mail, allowing alarms to have higher priority
Control interface for database maintenance

12 E-mail Command Interpreter

12.1 Description

A special e-mail address is assigned to this subsystem. E-mail sent here are parsed for get/set commands. Commands are carried out through the Data Server, and the result from get queries can be used to compose a return mail which is sent back to specified address.

12.2 Functional Requirements

Allow e-mails containing get, set and run commands to be processed and carried out [F42], [SAIDA 96]
Allow the result of get-commands to be returned to a specified address [F41], [SAIDA 96]
Allow prepared queries and return forms to be stored in a database [Not req.]
Allow running of stored queries by a run command [Not req.]

12.3 Functional Decomposition

Query and Response Form database
Command Interpreter
Control Interface (register/delete Query and Forms)

13 WWW Interface

13.1 Description

This is a simple interface to allow get/set functions to be requested via WWW. It will probably be implemented as cgi-scripts that simply call the get/set functions of the Data Server for named variables. Beside simple get/set requests, it will also allow a prepared html file with embedded SAIDA extensions to be processed dynamically.

This will work as follows: A WWW access to a certain URL location will trigger a cgi script, with a file name as parameter. This file will contain mostly standard html code, which will be copied unchanged to a temporary file. When a SAIDA get-command is found, a call to the Data Server will be performed, and the returned data is inserted in the output stream. Finally, the temporary file will be r eturned to the caller.

This communication is one way only. The client has to repeatedly poll if changes of variable values should be monitored. Therefore, the possibility offered by the Java programming language should be examined. If Java provides a way to let the server notify the client about events, then Java is probably a better ground for a WWW interface.

13.2 Functional Requirements

cgi access to Data Server get/set-functions [F5], [SAIDA 96]
cgi script for html files with embedded SAIDA data [F5], [SAIDA 96]
Evaluation of possibility to enable event-triggered communication to remote Java Applets [Not req.]

13.3 Functional Decomposition

Two or three simple cgi scripts (for parsing html files etc.)
Java test application

14 Service Application Interface

14.1 Description

This part of the system is not yet fully analysed. An abstract framework for applications, not only values, need to be defined in order to handle applications in an orderly way. It is our understanding that LCA provides such a framework, and it would be hazardous to do too much before we know more about LCA.

As a very minimum, the system will contain a telnet server and an ftp server to allow some basic access to the CCN. Existing standard applications will be used.

It would also be nice to have a general LCA Navigator accessible from remote. It is our understanding that LCA will contain a Navigator OLE object. If Network OLE is transparent enough to allow this object to run remote, but communicate with the CCN Object Server, then full LCA functionality might be possible from remote. On the other hand, should such an application including communication have to be developed by SAIDA, then substantial cuttings in other subsystems would probably be necessary.

Until a first estimation is performed on the above functionality, we have decided not to plan for this service.

15 Databases

Several possible ways exist to implement the needed databases.

own, hard-coded special RAM/file-based system
use the file system to implement the Data Server Variable Hierarchy
Some standard SQL database, accessed by embedded SQL
Use whatever database functionality LCA provides

A special solution might provide high performance, but might also be less attractive for a number of reasons.

The file system might work well for the Data Server Hierarchy, but is less useful for other purposes.

The last two alternatives both look possible. A standard SQL database would provide maximum flexibility and control. Using LCA will ensure consistency since SAIDA and LCA updates can be performed as atomic actions. A combination is also possible. We still know to little too decide, for instance how LCA databases are implemented.

16 Appendix A

16.1 Literature

[SAIDA 96] , SAIDA, "Requirements Specification" - Rev. A - University/College of Karlskrona/Ronneby, 1996.

Solution Decomposition
Abstract
1 - Client Components
2 - CCN Components Developed by SAIDA
3 - Other CCN Components
4 - System Overview
5 - Remote Development Environment Client (RDE Client)
5.1 - Description
5.2 - Functional Requirements
5.3 - Functional Decomposition
DISCLAIMER!
6 - Remote Development Environment Server (RDE Server)
6.1 - Functional Requirements
6.2 - Functional Decomposition
7 - Data Server
7.1 - Description
7.2 - Functional Requirements
7.3 - Functional Decomposition
8 - Logger
8.1 - Description
8.2 - Functional Requirements
8.3 - Functional Decomposition
9 - Alarm Handler
9.1 - Description
9.2 - Functional Requirements
9.3 - Functional Decomposition
10 - Remote Data Navigator Client
10.1 - Description
10.2 - Functional Requirements
10.3 - Functional Decomposition
11 - E-mail Handler
11.1 - Description
11.2 - Functional Requirements
11.3 - Functional Decomposition
12 - E-mail Command Interpreter
12.1 - Description
12.2 - Functional Requirements
12.3 - Functional Decomposition
13 - WWW Interface
13.1 - Description
13.2 - Functional Requirements
13.3 - Functional Decomposition
14 - Service Application Interface
14.1 - Description
15 - Databases
16 - Appendix A
16.1 - Literature