Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Software Engineering for Real-Time: A RoadmapH. Kopetz.Technische Universitat Wien, AustriaPresented by Wing Kit HorOutlineDifference 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 systemsIntroductionReal 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 domainsSoft vs Hard real-time systemSoft 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 machineHard real-time systemA failure to meet a specified deadline can lead to catastrophic consequences.Example: Computer system controlling a railway-shunting yardSoft 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 systemThe need of fail-safe hard real time systems are increasingTechnology trendsSystem on a Chip (SOC)Smart MEMS SensorsCOTS ComponentsInternet ConnectivityHigh-dependability systemsFuture real-time control systemDistributed 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 networksWhat is requiredTwo-level design methodologyDesign of architectureDevelopment of componentsWhat 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 NetworkWhat 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.ComponentSelf-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 provisionA unit for validationA unit of error containmentA unit for reuseA unit of design and maintenanceExample of a distributed systemComposabilityThe 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, testabilityTwo service classesPrior 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 InterfacesThe Real-Time-Service (RS) Interfacetimely real time service to the environmentThe Diagnostic and Management (DM) Interfacechannel for diagnosis and management of the serviceThe Configuration Planning (CP) Interfaceintegration of componentsThe Principles of ComposabilityIndependent 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 failuresThe 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 latencyThe Principles of Composability (cont.)ValidationProcess versus ProductWorst Case Execution TimeSimulationFormal VerificationConclusionTechnological 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 systemsConclusion (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 systemConclusion (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