Software Engineering for Real-Time: A Roadmap

Hermann Kopetz
Technische Universität Wien, Austria
email: hk@vmars.tuwien.ac.at

justified to partition a system along functional

hardware/software boundaries in order to avoid the extra
Abstract
software design and validation effort needed to cohabitate
The next ten years will see distributed real-time computer unrelated functions on the same hardware units. In such an
systems replacing many mechanical and hydraulic control architecture the issue of composability and reusability, how
systems in high-dependability applications. In these to build systems constructively out of pre-validated
applications a failure in the temporal domain can be as software/hardware components that provide well-defined
critical as a failure in the value domain. This paper functions, moves to the center of interest. Already today
discusses some of the technology trends that explain why this issue of composability is a key concern in the
distributed embedded real-time systems for high- development of industrial control systems.
dependability applications will move into the mainstream. It is the objective of this paper to speculate about the
It then investigates the new requirements that must be future of software engineering for real-time over the next
addressed by the software engineering process. Two of the ten years. The paper starts by discussing the fundamental
most important requirements are the design for difference between soft and hard real-time systems and
composability and the systematic validation of high- makes the assumption that the main challenge will be in the
dependability distributed real-time systems. In the last two design and validation of hard real-time systems for
sections, these issues of composability and validation are ultradependable applications. Since real-time architectures
treated in some detail. are strongly dependent on the hardware developments,
Section 3 deliberates about the visible trends in the field of
1. Introduction hardware and communication. Based on these trends,
Section 4 summarizes the requirements on future real-time
A real-time computer system is required to produce the system design and concludes that the most important
intended result before a specified point of physical time, the requirement is the support of composability. Section 5
deadline. This point of time is determined by the investigates this requirement in detail and postulates four
application the computer system is intended to service. The principles of composability for distributed real-time
controlling real-time software must be designed to generate systems. Section 6 focuses on the validation of high-
the correct behavior of the computer both in the value dependability systems. The paper closes with a conclusion
domain and in the temporal domain to meet this application in Section 7.
requirement. Since the temporal behavior depends on the
performance of the computer hardware, software
engineering for real-time systems must take into 2. Soft versus Hard Real-Time Systems
consideration the architectures and capabilities of the From the point of view of temporal performance, two
available computer hardware. It follows that the software types of real-time systems can be distinguished
design methods and architectures of real-time systems will (i) soft real-time systems: these are systems where a
be strongly influenced by the given hardware environment.
failure to meet a specified deadline reduces the utility
The impressive advances in the field of computer
of the result, but does not lead to a significant
hardware in the recent years make it economically feasible
financial loss. An example of such a system is a letter
that the old architectural proverb "form follows function"
sorting machine: If a letter is dropped into the wrong
becomes the guiding principle for the design of distributed
box because of a timing failure of the computer, no
real-time computer systems of the future. In nearly all but
serious consequences will result.
the high volume applications it will be economically
(ii) hard real-time systems: these are systems where a software specification and design technologies that are
failure to meet a specified deadline can lead to targeted specifically at real-time applications, such as real-
catastrophic consequences. An example of a hard time UML (Selic1999) or real-time CORBA (OMG 1998),
real-time application is a computer system controlling are not based on a sound model of time and do not consider
a railway shunting yard: If a wagon is released to the temporal properties as first order quantities, but rather as an
wrong track because of a timing failure of the addendum.
computer, a serious accident may occur.
>From these two simple examples it becomes evident,
3. Technology Trends
that the distinction between a soft- or hard real-time
computer system does not depend on the computer system The architecture of a real-time system is strongly
per se, but on the characteristics of the application the influenced by the capabilities and cost/performance of the
computer system is intended to serve. available hardware components. At present, the computer
In the not-too-distant past, the majority of the real-time industry in general and the semiconductor industry in
computer systems have been soft real-time systems: In particular is going through a period of revolutionary
many of the safety critical real-time applications an qualitative change that deeply affects the environment of
additional electrical, mechanical or hydraulic backup the system engineer designing hard real-time systems. In
system (without software) was included to take control (to this section, some of these important technological trends,
avoid a catastrophe) in case the computer system failed. as they relate to real-time system design, are presented.
This situation has been changing slowly over the last ten
3.1 System on a Chip (SOC)
years and will continue to change further over the next ten
years. With the successful deployment of software Today's level of VLSI technology makes it possible to
controlled flight control systems in civil aircraft (Airbus A produce a powerful computer node of a distributed system,
320, Boeing 777), many other industries, e.g., the including a 32 bit CPU, a megabyte of memory, I/O
automotive industry, intend to replace the expensive mixed circuitry and a network controller on a single silicon die.
technology approach to system control by distributed fault- Such a system-on-a-chip (SOC) offers many advantages
tolerant real-time computer systems without mechanical or from the point of view of functionality, dependability and
hydraulic backup. For example, in a "brake-by-wire" car, cost. According to the 1997 semiconductor road map,
the hydraulic connection between the brake pedal and the published by the Semiconductor Industry Association (SIA
brakes will be replaced by a fault-tolerant computer 1997) the number of transistors/cm2 will increase from
network (Hedenetz and Belschner1998). With the move of about 6 Mio to 24 Mio within the next 5 years, enabling the
these safety-critical control systems without backup into the production of much more powerful SOCs. The
mainstream of industrial control, the software engineering development costs of an SOC component are high--they
community is up to new challenges: the design of software can be in the order of 10 Mio US $, while the production
systems that are guaranteed to meet the specified deadlines costs are quite low, e.g. 10 US $. These very cost-effective
of ultra-dependable systems in all operational scenarios mass-produced SOCs are here to stay and will form the
within the stated load- and fault- hypothesis and the core hardware elements of future real-time control systems.
development of validation technologies that affirm that the 3.2 Smart MEMS Sensors
software is safe to deploy.
A smart device is the combination of a sensor or
In a hard real-time system, a failure in the temporal
actuator element and a local microcontroller that contains
domain is as critical as a failure in the value domain. Many
the interface circuitry, a processing element, memory and a
of the present-day software engineering techniques, such as
network controller in a single unit. More and more sensor
object-oriented design methods, focus on the value domain
elements are themselves microelectronic mechanical
and consider the temporal domain a low-level
systems (MEMS) (Frank 1995) that can be integrated on
implementation issue. Temporal properties are system
the same silicon die as the associated microcontroller. The
properties that depend on the proper cooperation of all
smart sensor technology offers a number of advantages
levels of a design: hardware, communication, operating
from the points of view of technology, cost and complexity
system, and application software. The design of hard real-
management:
time systems is thus fundamentally different from the
design of soft real-time systems or non real-time systems (i) Electrically weak non-linear sensor signals that
(Kopetz 1997), where the temporal properties of the lower originate from an MEMS sensor can be generated,
levels of an architecture are not explicitly considered conditioned, transformed into digital form and
during the design process of the higher level application calibrated on a single silicon die without any noise
software. In a hard real-time environment, it cannot be pickup from long external signal transmission lines
assumed that timeliness can be tested into a system, (Deirauer and Woolever 1998).
timeliness must the consequence of a rational system and (ii) It is possible to locally monitor the sensor operation
software design process. Even some of the more recent and thus simplify the diagnostics. In some cases it is

2
 possible to build smart sensors that have a single COTS components into larger systems requires
simple external failure mode--fail-silence, i.e., the precise and stable CNI specifications, both in the
sensor operates correctly or does not operate at all. value domain and in the temporal domain. Such
(iii) The interface of the smart sensor to its environment precise CNI specifications are a prerequisite for a
can be a simple well-specified digital communication thorough test of the components and for the
interface to a sensor bus, offering "plug-and-play" determination of the preconditions for the robust
capability if the sensor contains its own operation of the components in the new system
documentation on silicon. context. The present integration technologies, e.g., RT
CORBA (OMG 1998), do not address these issues of
(iv) The internal complexity of the smart-sensor hardware
temporal interface specification with the required
and software and the internal sensor failure modes
rigor. As soon as these interface problems are solved,
can be hidden from the user by a well-designed fully
we see a bright future for the hardware/software
specified smart sensor interface that provides just
components in the real-time market.
those services that the user is interested in. Thus, the
smart sensor technology can contribute to a reduction 3.4 INTERNET Connectivity
of the complexity at the system level. The connection of a control system to the INTERNET
The same arguments of cost reduction in volume can bring about a number of advantages, such as access to
applications apply to smart sensors as they apply to other WEB sites, remote monitoring of the controlled object,
SOCs. remote diagnosis of failures, etc.. However, there are two
3.3 COTS Components major problems with the present INTERNET technology in
real-time applications: lacking security and unpredictable
The above mentioned trends exert an enormous
temporal performance. While it can be expected that the
economic pressure on all but the large-volume applications
security problem will be solved in the near future because
to use Commercial-Off-The-Shelf (COTS) hardware and
of the enormous interest in electronic commerce, the
software components when designing new computer
lacking temporal predictability is here to stay for a longer
systems. Even large customers that traditionally have
time. The inherently bursty traffic pattern that is intrinsic to
designed their own special components, like the US DOD,
most INTERNET applications makes it difficult to
are realizing that cost-effective state-of-the-art system
guarantee dependable real-time performance with minimal
development can only be achieved if COTS components
jitter over the INTERNET.
are used.
We see three different types of COTS components in 3.5 High-Dependability Systems
the real-time system market: There is a visible trend to high-dependability
(i) hardware components as we have them today. In applications in the real-time control market. These high-
the future, the hardware components will provide dependability applications require fault-tolerant computer
more generic system services for the design of systems, because the application service must continue
distributed real-time systems, e.g., distributed clock even if parts of the control system have failed. Fault-
synchronization. tolerant computer systems will play an important role in the
(ii) software components, such as RT operating systems, future market for the following reasons:
that can be used in many different applications. One (i) The successful use of high-dependability computer
problem with the use of COTS software components systems in critical applications, such as flight-control
in real-time applications is that a software component systems, has opened large new markets for embedded
per se does not have any temporal properties--the computer systems in vehicles that up to now have
temporal behavior only emerges if the software is relied on mechanical or hydraulic control systems,
bound to a particular hardware component. It follows e.g., braking and steering.
that the user has to investigate the temporal (ii) The loss-of-service caused by a single failure of a
performance and the fault-modes (Fabre, Salles et al. control system, e.g., on an assembly line, even if not
1999) of a COTS software component on the selected safety critical, is often more significant than the cost
hardware platform. It is thus a myth that COTS of replicating critical hardware elements of the
software components can be integrated in high- control system hardware in order to provide a fault-
dependability real-time applications with little effort. tolerant control system that tolerates hardware
(iii) hardware/software components, such as a smart failures.
sensor that incudes the signal conditioning, (iii) In a fault-tolerant system the expensive "on-call"
calibration, diagnostic, and network control software maintenance can be replaced by the less expensive
and provides an established output signal across a regular preventive maintenance. The cost savings
stable standardized Communication Network associated with such a change in the maintenance
Interface (CNI). The constructive integration of

3
 strategy can be larger than the additional cost for In a "top-down" design process the lay-out of the
providing a fault-tolerant system. components must take the system-level specifications of the
CNIs as constraints for the implementation. In a "bottom-
up" design process the CNI interfaces of the existing
4. What is Required?
components provide the constraints for the architecture
When analyzing the above mentioned technology trends level design. This clean separation between architecture-
it can be concluded that the basic structure of future real- level design and component-level design, often performed
time control systems will be that of a distributed real-time in different organizations, requires a technology for the
system, consisting of a set of node computers connected by precise specification of the CNIs in the value domain and in
a communication system. Such a distributed real-time the temporal domain.
system will comprise two types of nodes, the powerful
system nodes, the SOC computers with the associated 4.2 Predictable Communication
peripheral devices, and the smart sensor nodes. The nodes "The network is the only mechanism suitable to enforce
will communicate via real-time networks. All nodes that are and manage real-time operation of distributed systems"
connected to a real-time bus form a cluster. Gateway nodes (Caro 1998). If the temporal properties of a network are
realize the connection between clusters. not stable, i.e., if the points in time of the acceptance of a
message by the network at the sender's CNI and the points
4.1 Two-Level Design Methodology in time of the delivery of the message by the network at the
The future software engineer will clearly distinguish receiver's CNI are not known a priori, then it is not
between two types of activities: the design of an possible to precisely coordinate the activities of the nodes
architecture and the development of the components. On in the temporal domain. Any unknown jitter caused by the
the architecture level the interactions among the network results in a degradation of the quality of service of
components must be specified and the communication control loops that are closed via the network.
network interfaces (CNIs) to the components must be It is much easier to reason about the correct operation of
defined and frozen, both in the value domain and in the a distributed real-time system if all nodes have access to a
temporal domain. At the component level, the global time (Kopetz 1997) of known precision than if they
development of the components, i.e. hardware software have not. The construction of such a global time is in the
units, that provide a defined service across the CNIs must responsibility of the network.
be accomplished, taking the architecture level CNI According to our view, the following two different real-
definitions as constraints. To support such a development time network types are needed in distributed control
process, a two-level design methodology is needed. applications for economic reasons (from the technical point
Consider the example of Figure 1, i.e., a distributed of view a single system network type would be sufficient):
real-time transaction between a stimulus (external interface (i) System Network: The system network connects the
EI1), visit to three components (processing component A, system nodes, the powerful SOCs. System networks
C, and E) and a response to the environment (external
must have distributed communication control and
interface EI6). This RT transaction can be decomposed
provide fault-tolerance such that the loss of any node
into three processing actions (at the components A, C, and
or a communication channel will not cause the failure
E) and two communication actions (B and D). If the
of the system network.
temporal properties of the intermediate interfaces (II2, II3 ,
II4, and II5 ) are frozen during the architecture design, then (ii) Sensor Network: The low-cost sensor network
it is possible to develop the components A,C, and E connects one or more system nodes to the smart
independently and to compose the temporal properties of sensors and actuators. Since the next generation of
the transaction out of the temporal properties of the low-cost sensor nodes will have imprecise on-chip
subsystems. If the temporal properties of the intermediate oscillators which require a periodic synchronization
interfaces are not specified during architecture design, then from a master with a good crystal oscillator, the
composability with respect to timeliness is not supported. sensor networks of the future will be multi-master
networks. Fault tolerance will be achieved by
EI1 II2 II3 II4 II5 EI6 replicating sensor nodes and replicating the sensor
network.
Processing Com. Processing Com. Processing
We assume that the complexity (and cost) of a network
A B C D E controller in a smart-sensor node of the sensor network and
the network controller in a node in the system network will
Real
differ by an order of magnitude. However, both networks
Time
must provide deterministic communication and a global
Stimulus from Environment Response to Environment time of known precision to all nodes.
Figure 1: Real-Time Transaction

4
4.3 Generic Fault Tolerance that implements the testbed for the component validation.
At present, many fault-tolerant real-time systems are The post conditions that must be satisfied by a correctly
application specific, requiring a significant amount of operating component form the basis for the acceptance test
additional application software for the implementation of of the component.
the fault-tolerance functions. In the future we see a need for A unit of error containment: All errors that occur
architectures that provide generic services for fault inside a component must be detected before the
tolerance, such as a fault-tolerant clock synchronization, or consequences of these errors propagate across a component
a membership service at the hardware or system software interface. Otherwise, a defective component can falsify the
level. Ideally, the application software for a fault-tolerant operation of other components by the provision of
system and a non-fault-tolerant system will be the same. corrupted output data across the component interface.
Ideally, a component should support the fail-silence
property: it either operates correctly (in the domains of
5. Composability time and value), is silent, or it produces a detectably
In classic engineering disciplines a component is a self- incorrect result without disturbing the other components in
contained subsystem that can be used as a building block in the system. If a component has no other than such clean
the design of a larger system. The components provide the external failure modes, fault-tolerance can be achieved by
specified service to its environment across the well- replicating replica-deterministic components.
specified component interfaces. An example of such a A unit for reuse: A component should be a unit for
component is an engine in an automobile, or the heating reuse. This requires that the component has standardized
furnace in a home. The component can have a complex interfaces with some flexibility to support the integration of
internal structure that is neither visible, nor of concern, to the component in diverse system contexts. For example,
the user of the component. the component interface should support name translation to
decouple the internal name space of the component from
5.1 What is an Ideal Component? the external name space of the environment. This interface
Ideally, the larger system should be constructed from flexibility should not require a revalidation of the
nearly autonomous components that can be integrated previously established component properties, such as
without violating the principle of composability: that correct operation or timeliness.
properties that have been established at the component A unit of design and maintenance: Finally, a
level will also hold at the system level. Examples of such component should be a unit of design and maintenance. It is
properties in the context of distributed real-time systems well-known that system structures evolve along
are timeliness and testability. An ideal component should organization structures. If the work output of an
be an autonomous unit that maintains its encapsulation organizational group is a nearly autonomous subsystem
when viewed from a number of different vantage points with well-specified interfaces, then the management of this
(Kopetz group is simplified. The error containment boundaries
1998) around a component reduce the possibility of unforeseen
A unit of service provision: Most importantly, a consequences of software maintenance actions.
component must a be unit of service provision. The service
is offered to the component environment across a real-time I/O Body Electronics
service interface. In a distributed real-time system, the Network
service consists of the timely processing and provision of Communication Driver Assistant Gateway
Network Interface System Body
the requested information. Since the validity of real-time
Interface (CNI) CC CC CC
information is time dependent, the specification of the within a node
precise point in time when the information must be present
at the component interface is of relevance. From the point CC CC CC CC
of view of the service user, the internal structure of the
Brake Power Steering Suspen-
component is irrelevant, as long as the specified Manager Train Manager sion
information is provided at the anticipated points in time.
A unit for validation: It must be possible to validate I/O I/O I/O I/O
the proper operation of a component in the value domain CC: Communication Controller
and in the temporal domain in isolation. The preconditions
for the correct operation of the component, both in the
domains of time and value, that must be satisfied by the Figure 2: Example of a distributed vehicle control system
component environment at the component/environment consisting of 7 nodes.
boundary must be precisely specified in the interface
specifications. The specification of these preconditions is Considering the proposed properties of an ideal
the input for the construction of an environment simulator component, a hardware/software unit, a node as outlined in

5
Section 3.3, seems to be the best choice for a component in 5.2 Component Interfaces
a distributed real-time system. Such a hardware/software From the point of view of complexity management and
unit is a self-contained SOC-computer with its own composability, it is useful to distinguish between three
processor, memory, communication interface, interface to different types of interfaces of a component: the real-time-
the controlled object, operating system and real-time service (RS) interface, the diagnostic and management
application programs. This hardware/software unit (DM) interface, and the configuration planning (CP)
performs a coherent function within the distributed interface. For the composability, the most important
computer system. interface is the RS interface.
Figure 2 shows an example of a possible future The Real-Time-Service (RS) Interface: The RS
integrated control system onboard a vehicle (Kopetz and interface provides the timely real-time services to the
Thurner 1998) with seven components. In this figure, the component environment during the operation of the system.
node replicas, that are introduced for the purpose of fault- In real-time systems it is a time-sensitive interface that
tolerance, are not depicted, nor is the replicated system bus must meet the temporal specification of the architecture in
shown. Each component consists of two parts, the all specified load and fault scenarios. The composability of
communication controller (CC) and the host computer that an architecture depends on the proper support of the
executes the application software. Between these two parts specified RS interface properties (in the value and in the
lies the communication network interface (CNI). temporal domain) during the operation. From the point of a
The grand challenge lies in the development of user, the internals of the component are not visible, since
architectures and software design methods for distributed they are hidden behind the RS interface.
real-time systems that support composability, that large The Diagnostic and Management (DM) Interface:
real-time systems can be built constructively out of The DM interface opens a communication channel to the
available components. A component property is said to be internals of a component. It is used for setting component
composable if the system integration will not invalidate this parameters and for retrieving information about the
property once the it has been established at the component internals of the component, e.g., for the purpose of internal
level. Examples of such properties are timeliness or fault diagnosis. The maintenance engineer that access the
testability. component internals via the DM interface must have
From the point of view of the analysis of a composable detailed knowledge about the internal structure and
architecture, it is reasonable to distinguish between the behavior of the component. The DM interface is not
following two service classes of an integrated distributed contributing to the composability. Normally, the DM
control system: interface is not time-critical.
(i) Prior Services: Given a component that has been The Configuration Planning (CP) Interface: The CP
developed independently to provide a specified interface is used to connect a component to other
service, e.g., the control of an engine by an engine components of a system. It is used during the integration
control system. This service has been validated at the phase to generate the "glue" between the nearly
component level and is thus available prior to the autonomous components. The use of the CP interface does
integration of the component into an integrated not require detailed knowledge about the internal operation
control system. We call such a service a prior of a component. The CP interface is not time critical.
service.
5.3 The Four Principles of Composability
(ii) Emerging Services: The integration of components
In a distributed system the components interact via a
into a system generates new services that are more
communication system as shown in Figure 2 to provide the
than the sum of the prior services. Take the example
emergent services. These emerging services depend on the
of a car: The integration of the four wheels, the
timely provision of the real-time information at the RS
chassis and the engine, all individual components,
interfaces of the components. The RS-interface is the only
give rise to a new level of service, the transport
interface that is relevant from the point of view of
service, that was not present at the component level.
composability. For an architecture to be composable, it
We call these additional services, that come about by
must adhere to the following four principles with respect to
the integration, the emerging services.
the RS-interfaces:
In a distributed real-time computer system, the
emerging services are the result of information exchanges (i) Independent development of components.
among the interacting nodes across the component (ii) Stability of prior services.
interfaces. Therefore, the communication system plays a (iii) Constructive integration of the components to
central role in determining the composability of a generate the emerging services.
distributed computer architecture.
(iv) Replica determinism.
These principles are discussed in detail in the following
sections.

6
 Independent Development of Components: A the timely interface service, are in conflict with the
composable architecture must distinguish sharply between resource requirements of the application software that
architecture design and component design. Principle one of implements the prior services of the component. In such a
a composable architecture is concerned with design at the situation, failures in the component services may occur
architecture level. Components can only be designed sporadically.
independently of each other, if the architecture supports the Constructive Integration: Principle three of a
precise specification of all component services at the level composable architecture is concerned with the design of the
of architecture design. In a real-time system the RS- communication system. Normally, the integration of the
interface specification of a component must comprise the components into the system follows a step-by-step
precise CNI specification in the value domain and in the procedure. The constructive integration principle requires
temporal domain and a proper abstract model of the that if n components are already integrated, the integration
component service, as perceived by the user of the of the n+1 component may not disturb the correct operation
component. Only then is the component designer in the of the n already integrated components. The constructive-
position to know exactly what can be expected from the integration principle ensures that this integration activity is
environment and what must be delivered by the component. linear and not circular.
Many of the present event-triggered architectures do not This constructive integration principle has severe
provide the capability to define the temporal properties of implications for the management of the network resources.
the CNIs with the required rigor. The exacts points in time If network resources are managed dynamically, it must be
when messages are expected to arrive or are supposed to be ascertained that even at the critical instant, i.e., when all
sent by a component, and the phase relationships between components request the network resources at the same
the messages are not contained in many CNI specifications. point in time, the timeliness of all communication requests
This loose specification of the CNIs makes it difficult for can be satisfied. Otherwise sporadic failures will occur with
the component designer to thoroughly validate a component a failure rate that is increasing with the number of
behavior in isolation, i.e., outside the system context. components integrated.
For example, if the peak-load scenario of service
requests to a component (rate and phase relationships real-time
between the requests) is not precisely specified at the network
architecture level, then vague assumptions about the delay critical application
system context of component use may replace the missing specific network
interface specifications. Such a component cannot be delay
validated independently and may not operate correctly in
another system context.
Stability of Prior Services: Principle two of a
composable architecture is concerned with the design at the
component level. A component is a nearly autonomous unit 1 2 3 4 5 6 number of nodes
that comprises the hardware, the operating system and the
application software. The component must provide the
intended services across the well-specified component Figure 3: Network delay at critical instant as a
interfaces. The design of the component can take function of the number of nodes.
advantage of any established software engineering
methodology, such as object based design methods. The For example, if a real-time service requires that the
stability-of-prior-service principle ensures that the validated maximum latency of the network must always remain
service of a component--both in the value domain and in below a critical upper limit (because otherwise a local time-
the time domain--is not refuted by the integration of the out within the component may signal a communication
component into a system. failure) then the dynamic extension of the network latency
For example, the integration of a self-contained by adding new components may be a cause of concern. In a
component, e.g., an engine controller, into the integrated dynamic network the message delay at the critical instant
vehicle control system may require additional (when all components request service at the same instant)
computational resources of the component to service the increases with the number of components. The system of
RS-interface, both in processing time and in memory space. Figure 2 will work correctly with up to four components.
Consider the case where the CNI is based on a queue of The addition of the fifth component may lead to sporadic
messages: memory space for the queue must be allocated failures.
by the component-local operating system and processing Other applications, e.g., when a time-sensitive control
time for the management of the queue must be made loop is closed by the network, may require a network of
available. In a time-critical component it may happen that known and constant jitter in order to support this principles
these additional resource requirements that are needed for of constructive integration.

7
 Replica Determinism: Principle four of a composable 6.2 Worst Case Execution Time
architecture is concerned with the implementation of fault- The temporal firewalls of a component, specified at the
tolerance by replication. A set of replicated components is architecture design level, identify the deadlines the
replica determinate (Poledna 1994) if all the members of component must meet under all specified operational
this set have the same externally visible state, and produce conditions. During component design is must be
the same output messages at points in time that are at most demonstrated, that these deadline will never be missed. A
an interval of d time units apart (as seen by the omniscient necessary prerequisite for this temporal validation is
outside observer). In a fault-tolerant system, the time knowledge about a tight upper bound of the worst case
interval d determines the time it takes to replace a missing execution time (WCET) of all time-critical process inside a
message or an erroneous message from a node by a correct component (Wilhelm 1999). This WCET analysis is an
message from redundant replicas. The implementation of important research area in the field of real-time software,
replica determinism is simplified if all components have the results of this research will have implications on other
access to a globally synchronized sparse time base. software areas, e.g., algorithm design, compiler design, and
operating system design. For example, many of today's
6. Validation compiler try to optimize the average execution time, even if
is this implies extending the WCET. In hard real-time
At the end of the development cycle it must be decided systems a small WCET is of utmost importance, while the
whether a given system is safe to deploy in the intended average execution time is of minor concern.
application domain. If this application domain is safety
critical, i.e., a failure of the computer system can result in 6.3 Simulation
high financial loss or even a catastrophe where human lives Large real-time systems require a closed loop
are endangered, then this decision is difficult. Many safety simulation in the laboratory to demonstrate that the system
critical applications demand a level of dependability that provides the intended services. In many cases, these
cannot be established by state of the art testing technology simulations will be real-time simulations, where the effects
(Littlewood and Strigini 1995). In this section we discuss of the real-time control system will be validated with
some trends in the field of validation of high dependability respect to a real-time simulation model of the controlled
real-time systems. object. In such an environment it is possible to study and
validate the fault-tolerance properties of the control system,
6.1 Process versus Product
since it is possible to inject faults and to generate
Since it is beyond the state of the art to validate by operational situations that will only occur rarely in the real
testing that a large real-time system is free of critical design environment (rare events). Such a rare-event simulation is
errors, the validation emphasis has shifted from the analysis also absolutely necessary to validate the peak-load
of the product to the analysis of the development process performance of a high-dependability system. Today the
of the product in the last few years (see, for example, the methodological support for closed loop real-time
well-known ARINC-178/B standard (ARINC 1992) for simulation and fault injection of large systems is already an
software in airborne systems). It is my opinion that this area of utmost industrial interest and this interest is likely to
trend will change during the next ten years. If composable increase over the next ten years.
architectures are widely deployed and real-time system
design is guided by the recursive application of the two step 6.4 Formal Verification
design methodology (see Section 4.1) then the emphasis A safety case is the accumulation of evidence from
will shift back to product (component) validation. System different sources that establishes the rational basis for the
design will consist of the reuse and integration of decision that a safety critical computer system is safe to
prevalidated hardware/software components. The temporal deploy. The formal analysis of critical algorithms that are
firewall concept (Kopetz and Nossal 1997), developed in used in the system can form a convincing argument in the
the context of the time-triggered architecture (TTA), safety case (Rushby 1993). The present formal validation
supports such a component validation by precisely technologies, e.g., have already achieved a level of maturity
specifying the value and temporal properties of the that allows them to contribute to the validation of safety
component interfaces at the architecture design level. These critical systems. In the future, the contributions of these
interface specifications establish the precondition and post formal methods are expected to increase.
condition for the component validation both in the value
domain and in the temporal domain. It is thus possible to
validate a component independently, i.e., outside the 7. Conclusion
system context. Practical experience with this concept have It is dangerous to write a predictive paper about
demonstrated the significant benefits of this approach technology trends if the period of prediction is small
(Hedenetz and Belschner 1998). enough that it is possible to confront the author--sometime
in the future--with a comparison of prediction versus

8
reality. Nevertheless I have engaged in this endeavor and 7923-9894-7, Third printing 1999. Boston. Kluwer
tried to outline a rough road map of the software Academic Publishers.
engineering issues in real-time systems over the period of
the next ten years. To me, the technological developments Kopetz, H. (1998). Component-Based Design of Large
in the field of the computer hardware and the demands of Distributed Real-Time Systems. Control Engineering
new high-dependability applications will dramatically Practice–A Journal of IFAC, Pergamon Press. Vol. 6.
change the environment of the real-time software engineer. pp. 53-60.
In my opinion, the most dramatic changes will be in the
fields of composable archtectures and systematic validation Kopetz, H. and R. Nosssal (1997). Temporal Firewalls in
of distributed fault-tolerant real-time systems. Large Distributed Real-Time Systems. Proceedings of
IEEE Workshop on Future Trends in Distributed
Acknowledgments Computing, Tunis, Tunesia. IEEE Press. pp. 310-315.

This work has been supported, in part, by the IST Kopetz, H. and T. Thurner (1998). TTP--A new approach
project DSOS. to solving the interoperability problem of
independently developed ECUs. SAE Congress 1998,
References Detroit, USA. SAE Press 981107. pp. 1-7.

ARINC (1992). Software Considerations in Airborne Littlewood, B. and L. Strigini (1995). Validation of
Systems and Equipment Certification. ARINC, Ultradependability for Software Based Systems.
Annapolis, Maryland. Predictably Dependable Computing Systems B.
Randell, J. L. Laprie, H. Kopetz and B. Littlewood
Caro, D. (1998). What Does Real Time Mean Anyway.
Ed. Heidelberg. Springer Verlag. pp. 473-493.
Instrument Society of America,
http://www.isa.org/journals/ic/octfloor/html. OMG, 9. (1998). Real-Time CORBA. Object Management
Group, Framingham, Mass.
Deirauer, P. and B. Woolever (1998). Understanding Smart
Devices. Industrial Computing. Vol. pp. 47-50. Poledna, S. (1994). Replica Determinism in Fault-Tolerant
Real-Time Systems. Technical University of Vienna.
Fabre, J. C., F. Salles, et al. (1999). Assessment of COTS
Rushby, J. (1993). Formal Methods and the Certification of
Microkernels by Fault Injection. Seventh Internatinal
Critical Systems. Computer Science Lab, SRI.
Working Conference on Dependable Computing, San
Selic, B. (1999). Turning Clockwise: Using UML in the
Jose, Cal. IEEE Press. pp. 19-38.
Real-Time Domain. Comm. ACM. Vol.42, No. 10,
Frank, R. (1995). Understanding Smart Sensors. London. Oct. 1999. pp.46-54
Artech House.
SIA (1997). National Roadmap for Semiconductors.
Hedenetz, B. and R. Belschner (1998). "Brake by Wire" Semiconductor Industry Association,
without Mechanical Backup by Using a TTP http://notes.sematech.org/ntrs/Rdmpmen.
Communication Network. SAE World Congress,
Wilhelm, R. (1999). Special Issue on Timing Analysis and
Detroit Michigan. SAE Press, Warrendale, PA, USA.
Validation for Real-Time Systems. R e a l - T i m e
Kopetz, H. (1997). Real-Time Systems, Design Principles Systems, Kluwer Academic Publishers. Vol. 17. pp.
for Distributed Embedded Applications; ISBN: 0- 127-287.