Tool Support for Distributed Real-Time Software

Abstract

The Problem.

In most publications on distributed real-time systems, even our own [2, 4], there is little, if any, discussion on the use of tools to enhance productivity in the software development process. To have the right tools, however, we need to know, first, for what? That is, we need to identify the right software architecture for distributed real-time software to make it a target of tool developers.

The primary difficulty in developing such a generic software architecture is to abstract its meaningful components, which are shared among the majority, if not all, models and applications. It has to include a number of components suitable to interact with external entities via: process interface, user interface, communication interface, and mass storage interface. One such architecture, which is based on the principle of feedback control as a real-time system has been recently described in [5]. It comprises all known models of of real-time applications: including feedback control systems, programmed control systems, data acquisition systems, multimedia and real-time simulation systems.

Software Architecture of a Distributed Real-Time System.

This architectural pattern representing essentially a single processor real-time system can be extended to a distributed architecture presented in Fig. 1. The software components must include parties responsible for the following interactions with all external elements:

• inputs from and outputs to the plant
• interaction with a user
• communication with other controllers/processors
• interaction with storage devices

enhanced by the processing (computational) capability and the time source.

Figure 1: Generic architecture of a distributed real-time system.

Depending on what is the focus of a distributed real-time architecture, there may be a variety of its particular instances. The example shown in Fig. 1 comes from the area of high-energy physics, where multiple data collection and control facilities are spread over a large area surrounding an elementary particle accelerator [1]. Multiple software units can be created to access various (maybe the same) sources and destinations of data and to exchange information among themselves. Any single unit can perform individual functions and communicate with every other unit.

This architecture is dynamic, which means that the organization of components and their interconnections may change during program execution. Adding or deleting new components should have no impact or minimal impact on the operation, in a sense that no degradation of functionality should occur due to such dynamic changes. Communication links can operate individually or be lumped into a middleware layer, with program units communicating partially or exclusively via this layer. A number of new components can be created and the architecture expanded during the run of an experiment or operation of a process.

Criteria for Tool Support.

Developing software architectures for contemporary real-time applications, such as those described in [1] is too complex to be done manually by a single individual. Therefore automatic tools are needed to assist in the development process. To be fully useful in the development the automatic tools have to provide support in the following four dimensions (Fig. 2):

 
Figure 2: Issues to consider when evaluating or selecting real-time design tools.

• internal, related to all aspects of expressing real-time models via the specific notation and respective transformations
• horizontal, related to means of communication with other models and other tools (for example, via TCP/IP protocol suite)
• vertical, related to the next and previous phases of the development process, with respect to support for code generation and prototyping, and support for design verification wrt. requirements
• diagonal, related to the use of architectural models in different projects and different processes.

Several software tools with this concept in mind operate already in the commercial marketplace. One study [6] focused on those, which have solid methodological foundations, based on object-oriented approaches, ROOM and UML, revealed several shorcomings with respect to the above mentioned 4 groups of criteria (dimensions).

In the internal dimension, the tools offer extensive capabilities to model both structure and behavior of distributed real-time software. The most important capability of this sort is to create executable models based on statecharts to study behavior (incl. animation). One serious disadvantage is the lack of capability to perform quantitative timing analysis at the design level. None of the underlying OO methodologies, ROOM and UML, supports that either.

In the horizontal dimension, both tools allow simple communication of models with external objects at the TCP/IP level using sockets. This is possible for both communication with other models of the same type and totally independent program units running on a remote platform of almost any kind supporting TCP/IP protocol suite. In practice, this allows team development and testing of a complex distributed real-time system on different platforms, in different programming languages.

In the vertical dimension, both tools allow code generation for most real-time kernels. What they lack, however, is the tracing capabilities to go back from the code or design to the requirements. What they partially allow, for example, is incorporating into design the modifications made to a class source file, but for the most primitive operations only, which is very inadequate for complex real-time systems.

In the diagonal dimension, the tools have very limited capabilities of importing models from other types of tools and exchanging models among themselves. This may change in the future with convergence of the whole industry towards a UML notation.

Bridging the Gap

How to bridge the gap between software architectures and their support tools? Ideally, the design tools should allow timing and scheduling analysis, then correcting the design, and finaly code generation for a specific platform or implementation standard. With current tools, timing analysis is only possible after the code has been generated, which means employing third-party tools working on imported trace files produced by the executables. There is hope, however, that the industry is heading in the right direction with the development of a Real-Time UML [3]).

When developing the basic structural components and defining their behaviors for distributed real-time systems, it turns out that a much more rigid communication structure is necessary for the whole design, than traditional distributed communication mechanisms can provide, based on sockets or remote procedure calls. This involves the necessity to use implementation level standards for distributed real-time communication: MPI/RT and Real-Time CORBA. The trouble is, however, that high-level design tools stop short of relating designs to any of the implementation standards, except real-time kernels.

In summary, studying the suitability of industry-strength tools for real-time software development to meet the requirements of distributed real-time applications, the following observations can be made:

• developing distributed real-time software can be based on a simple architectural framework and a few standard patterns
• software tools used to assist in the development must meet the four sets of standard criteria representing different views of the process
• the most serious disadvantage of current tools is the lack of capability to do timing and schedulability analysis at the design level
• another disadvantage is that the tools do not focus on any particluar real-time communication architecture (such as MPI/RT or RT-CORBA)

Janusz Zalewski
University of Central Florida