Software Engineering for Real- Time: A Roadmap H. Kopetz. Technische Universitat Wien, Austria...
-
date post
23-Jan-2016 -
Category
Documents
-
view
212 -
download
0
Transcript of Software Engineering for Real- Time: A Roadmap H. Kopetz. Technische Universitat Wien, Austria...
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