1 / 25

Software Engineering for Real-Time: A Roadmap

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 system Visible trends in the field of hardware and communication Requirements on future real-time system design

butch
Download Presentation

Software Engineering for Real-Time: A Roadmap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related