ELMAS Network

Infrastructure in general

• Client-Server communication secured using SSL
• Two-way certificate authorization between client/server
• User authentication using MD5 encrypted passwords
• Server side JDBC connection pooling

ELMAS network uses a three-tier architecture consisting of application client, server and database. Client communicates securely with server using SSL. Server is responsible for handling actual database connections using JDBC connection pooling to improve performance. Authentication is implemented in a non-database specific manner. User authentication uses MD5 encryption to avoid storing clear text passwords. SSL is implemented using self signed certificates and two-way authentication. In practice this means that client cannot establish a connection to server without a valid certificate, which improves server security.

In ELMAS network the client is much like the standalone ELMAS tool with extensions like storing project versions in a central database, using sub tree template catalogs as a starting point for developing a new project and having options to reference some existing data. If network connection is not present, the tool will still have the functionality of standalone version.

Server is a java-based application server with JDBC connection pools and support for SSL. Apache Tomcat is suitable for this use.

Relational database requirements include mature support for transactions, since concurrent read/write access to database is to be expected. Scalability is an issue, since lots of data are potentially available for a large amount of users. For heavy usage Oracle might be the recommended option. MySQL (with innoDB) is sufficient for moderate or small-scale usage. SQL Server or other common relational databases can also be used, since using database specific features will be avoided. There must however be a JDBC driver available for the database. (JDBC drivers are available for all most common databases.)

Users, groups and access levels

Access-levels (read, write, reference) are assigned to tree-releases and are granted for groups of users. Administrators can create new groups. With each group there is also a manager group. A user belonging to such manager group is granted the user administration privilege for that specific group. This includes creating new users and adding/removing users to/from the group.

In group-oriented way of managing user privileges users are listed for the selected group. In user-oriented way of handling user privileges groups are listed for the selected user. A user may naturally belong to several groups and manager groups. If a user is granted administrator privileges, the user has unlimited access rights and thus can do everything.

Projects

In general projects consist of fault trees and event trees. A single project may be a mixture of success logic and failure logic. Naturally projects may contain any kind of data that can be constructed in a standalone ELMAS. This involves FMEA and hyperlinks for example.

Version handling

Instead of just saving different stages of projects with different names and naming conventions, a 3-level version handling scheme can also be utilized. Project version handling includes levels major, minor and patch. Version tags have free format, but length is limited to 64 characters. Length of project name is limited to 128 characters. For longer explanations there is a notes-field with no length limit. It is not necessary to use all or even any of the available version levels, but it is highly recommended. Well organized versioning makes it easier for example to find out the current stage of the project of interest. To some extent it also enables to see the design path that has lead to the current stage.

• Versioning is determined while saving project
• Versioning is available for Own projects, Releases and Templates alike
• Granting access for user groups is available for Releases and Templates
• Own projects can be used to store incomplete draft version

Releases and access levels

When a user has completed constructing a success/failure/event tree for some system, component or event, it is possible to release the tree to be accessed by others. The purpose of Read and write access-levels is self-evident. When a user has the Reference-access right to some release, the user is allowed to link to that release from some other project. In practice this means that the release is referenced as a sub tree in the master project. The master project shows the released sub tree, but the creator of the release (or someone else with write-access to the release) is responsible for maintaining and updating that release. Selecting the release to be referenced in a master project is done by using a release catalog. Release catalog view is somewhat similar to the normal project and version handling view. The user gets to see just the releases that she is authorized to see. The authorization of a user is determined by the access rights of the groups that the user is assigned to. If a user is assigned to different groups that have different rights to some project, then all the granted rights together form the access rights of the user.

Templates

Templates are like released trees that can be copied and taken to be the starting point of some other use. Releasing a template is done like releasing a normal tree and selecting the authorized groups to grant rights to. The exception is that for templates there are just read- and write- access levels available to be granted to groups.

If a user has read access to a template, she can take a copy of the template and is free to use and modify the copy as she sees best. If a user has write access to a template, she can modify the template itself. There is no reference access level for templates, since the only way of using them is by taking a copy of the template for own usage.