Software Engineering for Real-Time: A Roadmap

1. Software Engineering for Real-Time: A Roadmap H. Kopetz. Technische Universitat Wien, Austria Presented by Wing Kit Hor

2. Outline • Difference between soft and hard real-time system • Visible trends in the field of hardware and communication • Requirements on future real-time system design • Three principles of composability • Validation of high-dependability systems

3. 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

4. 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

5. 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

6. Technology trends • System on a Chip (SOC) • Smart MEMS Sensors • COTS Components • Internet Connectivity • High-dependability systems

7. 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

8. What is required • Two-level design methodology • Design of architecture • Development of components

9. 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

10. 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.

11. 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.

12. 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

13. Example of a distributed system

14. 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 property once it has been established at the component level • Examples: timeliness, testability

15. 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.

16. 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

17. 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.

18. 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

19. 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

20. The Principles of Composability (cont.)

21. Validation • Process versus Product • Worst Case Execution Time • Simulation • Formal Verification

22. 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-tolerant real-time systems

23. 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

24. 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.

25. Thank You