Software Engineering for Real-Time: A Roadmap

H. Kopetz.

Technische Universitat Wien, Austria

Presented by Wing Kit Hor

Outline

Difference between soft and hard real-time systemVisible trends in the field of hardware and communicationRequirements on future real-time system designThree principles of composabilityValidation of high-dependability systems

Introduction

Real time systems Systems that are required to produce the

intended result at (or around) a specific point on the time scale.

They are measured in both value and temporal domains

Soft vs Hard real-time system

Soft real-time system A failure to meet a specified deadline reduces the utility

of the result, but does not lead to a significant financial loss

Example: Letter sorting machine

Hard real-time system A failure to meet a specified deadline can lead to

catastrophic consequences. Example: Computer system controlling a railway-

shunting yard

Soft vs Hard real-time system (cont.)

Distinction is based on characteristics, application, environment, not the computer system itself.Initially deployed real time systems were soft real time systems Need additional backup system

The need of fail-safe hard real time systems are increasing

Technology trends

System on a Chip (SOC)

Smart MEMS Sensors

COTS Components

Internet Connectivity

High-dependability systems

Future real-time control system

Distributed real-time system Consisting of a set of node computers

connected by a communication system Two type of nodes:

Powerful system nodes Smart sensor nodes

Real-time networks

What is required

Two-level design methodology Design of architecture Development of components

What is required (cont.)

Predictable Communication Not possible to precisely coordinate the

activities if time needed is unknown Unknown jitter of network -> degradation of

QOS. Network type suitable for distributed control

applications: System Network Sensor Network

What is required (cont.)

Generic Fault Tolerance Present: fault-tolerant real-time systems are

application specific: Require additional application

Future: Architectures to provide generic services for fault tolerance.

Ideally, the application software for a fault-tolerant system and a non-fault-tolerant system will be the same.

Component

Self-contained subsystem that can be used as a building block in the design of a larger system.

Example: Engine in an automobile Heating furnace in a home.

What is an ideal component?

A unit of service provision

A unit for validation

A unit of error containment

A unit for reuse

A unit of design and maintenance

Example of a distributed system

Composability

The grand challenge lies in the development of architectures and software design methods for distributed real-time systems.

Composable property If system integration will not invalidate this pro

perty once it has been established at the component level

Examples: timeliness, testability

Two service classes

Prior Services Developed independently to provide a specified

service.

Emerging Services Integration of components into a system

generates new services that are more than the sun of the prior services.

Component Interfaces

The Real-Time-Service (RS) Interface timely real time service to the environment

The Diagnostic and Management (DM) Interface channel for diagnosis and management of the

service

The Configuration Planning (CP) Interface integration of components

The Principles of Composability

Independent Development of Components Must distinguish between system design and

component design Architecture supports the precise specification

of all component -> components can be designed independently.

Precise specification of interfaces in both value and time domain.

The Principles of Composability (cont.)

Stability of Prior Services The component must provide the intended

services across the well-specified interface. The validated service of the component should

not be compromised by integration into any system context

The prior service for some of them might require additional resources -> vulnerability to failures

The Principles of Composability (cont.)

Constructive Integration Step by step incremental integration Newly added components may not disturb the

correct operation of the already integrated components

Concurrent use of network resources, might increase latency which should be less than the maximum latency

The Principles of Composability (cont.)

Validation

Process versus Product

Worst Case Execution Time

Simulation

Formal Verification

Conclusion

Technological developments in the field of the computer hardware and the demands of new high dependability applications will dramatically change the environment of the real-time software engineering.Most dramatic changes: Composable Architectures Systematic validation of distributed fault-tolera

nt real-time systems

Conclusion (cont.)

Strengths of the paper The paper identifies certain key concerns of

real-time system. Provide viable methodology/requirement to

archive the technology trends. Appropriate and concise suggestions on

increasing the composability of components. Relevance to embedded system

Conclusion (cont.)

Weakness of the paper Do not suggest a practical model and technical

details of a Real-time Network (with low/no jitter), which I interested most.

Do not mention the rule of Real-time Operating System (RTOS) in Real-time system explicitly.

Too focus on distributed Real-time system.

Thank You