Software Engineering For RealTime: A Roadmap - PowerPoint PPT Presentation

1 / 14
About This Presentation
Title:

Software Engineering For RealTime: A Roadmap

Description:

Emerging services, provided by integration of multiple ... Component designers will need to establish tight upper bounds for all time-critical processes ... – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 15
Provided by: georgethom
Category:

less

Transcript and Presenter's Notes

Title: Software Engineering For RealTime: A Roadmap


1
Software Engineering For Real-Time A Roadmap
  • Author Hermann Kopetz
  • Technical University of Vienna, Austria
  • lthk_at_vmars.tuwien.ac.atgt
  • Presenter George Edwards
  • University of Southern California
  • ltgedwards_at_usc.edugt

2
Presentation Overview
  • Introduction
  • Technology Trends
  • Requirements for Real-Time Systems
  • Composability
  • Validation
  • Critique of the Paper

3
Introduction
  • Increasingly widespread and important
  • Avionics, telecommunications, medicine, and
    defense applications
  • New challenges for software engineers
  • Resource constraints
  • Stringent quality-of-service (QoS) demands
  • Availability, security, scalability
  • Composability of COTS components
  • Validation of component-based architectures

Distributed, Real-Time, Embedded (DRE) Systems
4
Technology Trends (1/2)
  • Advances in the semiconductor industry will have
    a strong influence on SE for RT
  • RT systems composed of two types of hardware
    components
  • System-on-a-chip (SOC)
  • High dependability, low-production costs
  • Smart microelectronic mechanical systems (MEMS)
    sensors
  • Signal conditioning, calibration, diagnostics,
    and network control

5
Technology Trends (2/2)
  • Economic factors demand that complex, large-scale
    systems be composed of commercial-of-the-shelf
    (COTS) components
  • A component is a self-contained subsystem used as
    a building block in a larger system
  • Hardware components
  • Software components
  • Combined hardware/software components
  • A self-contained SOC with OS and RT application

6
SE Requirements for DRE Systems (1/3)
  • Two-level design methodology
  • Strict separation of architectural design and
    component development
  • Architectural level component interactions and
    communication network interfaces
  • Component level implementation of defined
    services
  • Requires precise specification of CNIs in both
    value and temporal domains
  • Enables system analysis without knowing component
    implementations

7
SE Requirements for DRE Systems (2/3)
  • Predictable communication
  • Two types of real-time networks
  • System networks connect SOCs
  • Sensor networks connect SOCs to smart sensors
  • Both network types must
  • Have stable temporal properties
  • Provide a global time of known precision

8
SE Requirements for DRE Systems (3/3)
  • Generic fault-tolerance
  • Architectures that provide generic services
  • Achieved through distributed communication
    control and replication
  • Provided by the network, hardware, and system
    software
  • Application software for fault-tolerant and
    non-fault-tolerant systems is the same

9
Composability
  • Components must be autonomous and encapsulated
  • Various possible vantage points
  • Service provision
  • Validation
  • Error containment
  • Reuse
  • Design and maintenance
  • Design methodology must ensure these properties
    are not invalidated by system integration.

10
Service Classes
  • Analysis of component-based architectures should
    distinguish
  • Prior services, provided by an individual
    component
  • Emerging services, provided by integration of
    multiple components

11
Component Interfaces
  • Real-time Service (RS) interface
  • Hides component implementation
  • Provides a service according to the CNI spec
  • Diagnostic and Management (DM) interface
  • Exposes component implementation
  • Allows configuration and fault diagnosis
  • Configuration Planning (CP) interface
  • Generates glue code

12
Principles of Composability
  • Independent development of components
  • System architecture does not rely on specific
    component implementations, only interfaces
  • Stability of prior services
  • Validated services not affected by integration
  • Constructive integration
  • Introduction of a new component does not
    interfere with correct system operation

13
Validation
  • Composable architectures will shift emphasis back
    to product validation
  • Component designers will need to establish tight
    upper bounds for all time-critical processes
  • Rare-event simulations (faults, peak-load
    performance) will be required
  • Formal verification methods will grow in
    importance

14
Critique of the Paper
  • Strengths
  • In depth analysis of composability and validation
  • Very specific view of the future of RT systems
  • Weaknesses
  • Somewhat narrow focus ignores many important
    issues
  • As much about hardware as software
  • Relevance to embedded systems
  • Embedded systems are almost always RT systems
Write a Comment
User Comments (0)
About PowerShow.com