The PROBAnD Railway Crossing Specification

Contribution to the SDL-2000 Design Contest of the 3rd SAM Workshop

Stefan Queins, Andreas Metzger

The railway crossing design contest has been approached with an extension of our requirements engineering method PROBAnD (Prototyping-, Reuse-, and Object-based Building Automation Development), which has originally been developed for specifying complex building automation systems software. This method is presented in detail in our research paper contribution to the SAM 2002 workshop called "Early Prototyping of Reactive Systems Through the Generation of SDL Specifications from Semi-formal Development Documents".

To better understand our design contest results (especially the final SDL specification), which have been attained with an extension and modification of the PROBAnD method, an informal description of the method's development activities and documents will be given in this document.

Fig. 1: Overview of the PROBAnD Requirements Engineering Method

As an input, the requirements engineering method PROBAnD takes the problem description, which is divided into the building description and a collection of needs (c. f. Figure 1).

The building description contains a description of the building’s structure. Further, the building’s installation is depicted. From this building description, an initial control system structure can easily be derived because the control objects are most often identical to the the building’s objects or are a sub-set of these. To handle the huge number of control objects, control object types are formed, which are aggregated according to the hierarchy of the building’s objects. As requirements engineering proceeds, this control system structure can be refined, as long as the strict aggregation hierarchy of control object types is maintained.

The other part of the problem description is made up by a collection of needs. These needs informally describe the control system from the point of view of the users. The needs are split into less complex control tasks such that they can be assigned to single control object types.

As a guideline for the above steps, we suggest that the responsibilities of a control object type at a certain level should match the control tasks that can be performed at that level, which allows minimizing the flow of information. This distribution of responsibilities, which can easily be applied in the domain of building automation systems, has similarities to an organizational hierarchy. Communication between control objects is realized through the exchange of signals (which may have parameters) that are only allowed to travel along the aggregation hierarchy. This helps maintaining the easy comprehensibility of the specification, and allows the creation of documents from a set of few templates to simplify recurring activities (like specifying communication channels between control object types).

After the control object types have been identified and control tasks have been assigned, strategies for realizing the control tasks are informally given in natural language, leading to a collection of semi-formal control object types, which are expressed in HTML documents.

From these semi-formal control object types, operational control object types are specified in SDL documents, which together form an executable SDL specification.

The executable specifications are used for creating control system prototypes, with which the test of the systems becomes feasible. To ease the interaction with the system during run-time, Java panels (GUIs) can be used that allow the dynamic change of parameters and settings.

One important aspect of our process is that the development time for creating and modifying each document is recorded (for each document a "Version History" is kept), which allows measuring the overall development effort.

Design Contest Results: