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