EmSys Summer School University of Salzburg, 2003 Embedded ... · Adelard ARCS CNUCE JRC LAAS...

EmSys Summer SchoolUniversity of Salzburg, 2003

Embedded Systems Roadmaps in the EUThe DES (Dependable Embedded

Systems) – Roadmap

Salzburg, July 2nd, 2003

EmSysEmSys Summer SchoolSummer SchoolUniversity of Salzburg, 2003University of Salzburg, 2003

Embedded Systems Roadmaps in the EUEmbedded Systems Roadmaps in the EUThe DES (Dependable Embedded The DES (Dependable Embedded

Systems) Systems) –– RoadmapRoadmap

Salzburg, July 2nd, 2003

FP5.8 KAII Roadmapping projectIST – 2001 - 37553

Erwin SchoitschARC Seibersdorf Research, Vienna/Seibersdorf

Adelard ARCS CNUCE JRC LAAS Newcastle UniversityEmSys - Embedded Systems – Summer School, Salzburg, July 2nd, 2003.

DDSIDependability

policy support

DES in AMSD: Positioning as a “Meta-Roadmap Exercise”

DES in AMSD: Positioning as a “MetaDES in AMSD: Positioning as a “Meta--Roadmap Exercise”Roadmap Exercise”

Other Sources….. (especially for foresight and prioritization needed)DES-Roadmap: specific Co-operation with ARTISTIntegration of Dependability, Embedded Systems and Critical RT-Control

AMSDOverall dependability

AMSDdependable embedded

systems

RESETsmartcards

PAMPASmobile

privacy &security

BVNbiometrics

RAPIDPrivacy/IdentityMgmt

ACIPcritical

infrastruct.protection

STORKcrypto

ARTISTAdvanced

RT

„Do not re-invent the wheel“ „Compile a consistent view“


Characteristics of Embedded SystemsCharacteristics of Embedded SystemsCharacteristics of Embedded Systems

Ø Software – intensive Systems: Software plays the major role in a “Real World System”, holistic view of the system, HW/SW architecture interdependencies

Ø Embedded Systems: Combination of processors, sensors, actuators, “intelligence”, “hidden computers” and massive deployment, intensive interaction with uncertain environment: “A physical process with dynamics, fault, noise, dependability, power, size (in general: resource -) and memory restrictions…” (Foundational Infrastructure needed)

Ø Embedded Software: new capabilities to HW transducers added by “embedded software” (“defines physical behaviour of a complex non-linear device”), HW/SW co-design, dependability, low power, timeliness, … characteristics


DES – Roadmap: ObjectivesDES DES –– Roadmap: ObjectivesRoadmap: Objectives

Application domains selected:• Automotive (“driver”) • Aerospace (“established”)• Transport (railways) (“emerging”)• Industrial automation & process control (“established”)• Medical devices/systems (“emerging”)• Partially included: Research needs of the telecommunications area and Long Term Research issues as far as relevant for the application domains

Systems are NOT always safety-critical by design – often the actual criticality and dependability levels rise based on our desire for enhanced reliance on them !!


DES Roadmap, ProcessDES Roadmap, DES Roadmap, ProcessProcess

• Application assessment (analysis of the different application domains)

• Technology assessment (study of the available performance and cost predictions of the enabling technologies, namely semiconductors, communications, dependability, and real-time system and software development)

• Analysis of the resulting technology/application matrix to identify which fields particularly merit further work, leading to

• Establishment of a research agenda

Methodology: Analyses and Synthesis of 17 Roadmaps and of many other sources (workshops, working groups, expert interviews and reviews, documents, AMSD conference)


Application Assessment: Human centered, Vision-Driven

Application Assessment: Human Application Assessment: Human centeredcentered, , VisionVision--DrivenDriven

Ø Automotive: Accident free DrivingØ Avionics: Safe Sky for EuropeØ Medical: Robot SurgeonØ Communications: Seamless

ConnectivityØ E-Life: Ubiquitous Computing,

environment awarenessØ personalised (user centered,

dynamically adapted to user preferences),

Ø dependable (time dynamics, timely responsiveness, secure),

Ø context-awareness (person, object, location, time),

Ø natural interaction

Industrial Vision:

„Aerospace Safety at Automotive Cost“

Industrial Need: From Supply Chain to Design Chain


Sectoral Trends identified(Results Grenoble WS plus other sources)

SectoralSectoral Trends identifiedTrends identified(Results (Results GrenobleGrenoble WS plus other sources)WS plus other sources)Trends in Automotive:Ø X-by-wire: integrated steering, brakes, airbags, suspension by

wire Ø Intelligent Transport Systems, IntermodalityØ Integrated communication, driver’s guidance and entertainmentØ Integrated Engine control, power managementØ HCI: Display management

Advanced Driver Assistance by:Ø Vehicle-side embedded systemsØ Roadside embedded systems and interactionØ Global connectivity: vehicle – to –vehicle (long term), satellite,

traffic navigation and control (see Embedded Systems Scenario “Eve – a day of driving”).

Ø eSafety on the road: Need for Standardization !!!Ø Autonomous Driving, “Platooning” of vehicles



SectoralSectoral Trends identifiedTrends identified(Results (Results GrenobleGrenoble WS plus other sources)WS plus other sources)

Trends in Avionics:Ø Integrated Modular Avionics (IMA)Ø Modular Aerospace Controls (MAC)Ø Global Infrastructure for ATCØ Cockpit-, Display management, fuel management, engine control

Trends in Industrial Automation:Ø Openess (standardization, different vendors)Ø Maintainability, Replacement, Re-IntegrationØ Smart Sensors, Distributed (Networked) SystemsØ Use of Internet for Monitoring and ControlØ Specific needs of large scale critical infrastructures: e.g. energy

suppliers/networksØ Includes large facility management, “intelligent houses”



SectoralSectoral Trends identifiedTrends identified(Results (Results GrenobleGrenoble WS plus other sources)WS plus other sources)Trends in RailwaysØ move to more openness, competing operators, infrastructure

providersØ Unrestricted cross-border traffic and interoperabilityØ move from national and proprietory equipment (and procedures !)

to standards (interfaces, components, sensors) and COTS communication

Ø Move to ERTMS and Euro-Interlocking (instead of proprietorysolutions)

Ø Fixed interlocking and track bound equipment (signalling, train control) combined with on-board equipment and wireless communication (GSM-R, GPS)(ETCS Level 1, 2)

Ø Global Connectivity, train control (Satellites, GPS)Ø Remote Monitoring and Maintenance, info for service suppliersØ Updated information (JIT) for passengers, freight, traffic

management (multimodal)


Trends in Medical – Component Healthcare SystemTrends in Medical Trends in Medical –– Component Healthcare SystemComponent Healthcare System

Around us ...

… inside us ?

Products and equipmentat the service of individuals

MicroMicro--capsulecapsule


Sectoral Trends identified(EWICS TC7 WG Medical Devices, Rail)

SectoralSectoral Trends identifiedTrends identified(EWICS TC7 WG Medical Devices, Rail)(EWICS TC7 WG Medical Devices, Rail)

Trends in Medical SystemsØ Move from direct face-to-face medical support to remote

supervision and monitoring automated devices for control of long-term medication and treatment

Ø new means of interaction and surgery of medical devices (MEMS, nano-devices)

Ø smarter healthcare systems: automated “error-free” provision and protection of medicine, data/critical assets and support (critical clinical processes) in hospitals (EU-project DRIVE – Drug in Virtual Enterprise)

Ø “Component” Healthcare systems: Integration of components each fitting a specialised role in the healthcare chain

Linking to global infrastructures: strong interaction with Overall Dependability Roadmap and the other roadmaps

Enabling Technology for all of these trends: DES !!


The Challenge (Results of the GrenobleWorkshop Oct. 2002)

The Challenge (Results of the The Challenge (Results of the GrenobleGrenobleWorkshop Oct. 2002)Workshop Oct. 2002)

• The challenge is to facilitate the systematic design of large dependable control systems out of components. The interactions of the components is realized by the exchange of messages across linking interfaces (LIFs) to a real-time communication system.

• The driving forces for the composition of a large System of Systems (SoS) out of a set of components (component systems) are:

– Cognitive complexity reduction in order to reduce the design and development effort

– Reuse of components: The components may be newly designed according to a given architectural style or may be already existing systems (legacy systems).

– Simplified diagnostics and repair.




Safety Systems Concerns:• resources shared between functions (encapsulation of task environs)• stronger interactions among them• more functionality at less cost (cost explosion in development ?!)Safety is a system property:• New hazards arise from fault propagation in composed systems and

unintended emergent behaviour• Development of semi-standardized components, packaged with a

certification argument or "pre-certified"• System calibration will become largely a composition of component-

level pre-certification arguments




Need for modular Safety Analysis and Certification, depending on• Partitioning• Safety Function• Controlled FailureTrends in component-based DES:Development of semi-standardized components, packaged with a

certification argument or “pre-certified”System calibration will become largely a composition of component-

level pre-certification argumentsFoundational infrastructure required: TT-paradigm

Building Blocks for HRT Middleware, System Simulation and Emulation (Co-Design/Co-Simulation), Performance Modeling




Challenges in System Design and Architecture:• The challenge is to facilitate the systematic design of large

dependable control systems out of components. The interactions of the components is realized by the exchange of messages across linking interfaces (LIFs) to a real-time communication system.

• The driving forces for the composition of a large System of Systems (SoS) out of a set of components (component systems) are:

– Cognitive complexity reduction in order to reduce the design and development effort

– Reuse of components: The components may be newly designed according to a given architectural style or may be already existing systems (legacy systems).

– Simplified diagnostics and repair.


Challenge of Future Failure Modes of SoCChallenge of Future Failure Modes of Challenge of Future Failure Modes of SoCSoC

• The expected further shrinkage of the feature size will cause new failure modes1 such as, for example:

– Transient multi-bit failures caused by a single fault event– Intermittent failures of the interconnect that can affect

different functions on the die simultaneously• It is expected that in the future the rate for permanent failures

will remain unchanged, but that the rate for intermittent and transient failures will increase.

• The assumption that a fail-silent node can be implemented on a single die that hosts two independent FCUs is not sustainable in future high-dependability applications.

1 Source: C. Constantinescu, Impact of Deep Submicron Technology on Dependability of VLSI circuits, Proceedings of theIEEE DSN 2002, Washington D.C., p. 205-209


Additional Problems identified (Results Grenoble WS (1))

Additional Problems identified Additional Problems identified (Results (Results GrenobleGrenoble WS (1))WS (1))

Ø Interfaces of components (temporal properties, specification of interface models)

Ø Testing and Diagnosis (far away from advanced methods, definition of test cases ? Formal methods ? On-line vs. off line)

Ø Dynamic reconfiguration, re-integration and identification of components (“hidden computers”)

Ø Massively deployed MEMS, transducersØ Autonomous decision making, controlled interaction in

uncertain physical environmentØ Autonomous functioning, fault tolerance, robustnessØ Concerns on methods and tools


Additional Problems identified (Results Grenoble WS (2))

Additional Problems identified Additional Problems identified (Results (Results GrenobleGrenoble WS (2))WS (2))

Ø Human factors (user reaction in operation, operational surprises, adaption of users behaviour (safer car = more risky driving vs. can driver manage his “smart” car ?)

Ø Standardization and certification issues (components, interfaces, system integration, human and environment interaction)

Ø Assessment and evaluation issuesØ Cultural differences in different application areas and of users,

matching between education and industrial practices (students available as drivers for use of methods and tools, industry influencing curricula etc.)


DES Roadmap – First Roadmap Synthesis

DES Roadmap DES Roadmap –– First Roadmap First Roadmap SynthesisSynthesis

The following Roadmap documents were considered:[RM SW-Intensive] ITEA – Technology Roadmap on Software Intensive Systems,

ITEA Office Association, Eindhoven, March 2001[RM Semiconductors] International Technology Roadmap for Semiconductors

(SIA, 1999+2000), (System on a Chip (SoC), Test and Test Equipment)[RM SW Engineering] Anthony Finkelstein (Ed.) , The Future of Software

Engineering, several articles on Software Engineering Roadmaps. July 2000 (ICSE 2000), publ. by ACM, ISBN 01-58113-253-0.

[RM Embedded] Embedded Systems Roadmap 2002, Ludwig D.G. Eggermont(ed.), STW [Strategic] The Embedded Software Strategic Market Intelligence Program 2001/2002 (Executive White Paper only!)

[RM Real-Time] Software Engineering for Real-Time: A Roadmap, Kopetz, 2000.[RM SW Safety] Software Engineering for Safety: A Roadmap, Lutz, 2000[RM SW Dependability] Software Reliability and Dependability: a Roadmap,

Littlewood, Strigini, 2000




[Strategic] The Embedded Software Strategic Market Intelligence Program 2001/2002 (Executive White Paper only!)

[RM SW Architecture] Software Architecture: a Roadmap, Garlan, 2000.[RM Requirements Engineering] Requirements Engineering: A Roadmap,

Nuseibeh, Easterbrook, 2000.[RM Middleware] Software Engineering and Middleware: A Roadmap, Emmerich,

2000.[RM Testing] Testing: A Roadmap, Harrold, 2000.[RM TTA] A Roadmap for Time-Triggered Architectures, Kopetz, 2003.[RM HRT] Hard Real-Time Development Environments. ARTIST Draft Roadmap

May 2003[RM Curr] Guidelines for a Graduate Curriculum on Embedded Software and

Systems. ARTIST Draft Roadmap May 2003[RM Comp] Component Based Design and Integration Platforms. ARTIST Draft

Roadmap May 2003[RM QoS] Adaptive Real-Time Systems for Quality of Service Management.

ARTIST Draft Roadmap May 2003




Document “R&D Top-Level Synthesis of Roadmaps”:2 – step – procedure:Step 1: Chapter wise analysis of the document, verbal quotations or

condensations of challenges, recommendations or requirementsStep 2: Synthesis by selection of R&D challenges seeming to be relevant

for DES (dependable embedded systems) + GAP Analysis1. Requirements, Specifications2. Architecture, Design3. Realisation4. V & V5. COTS, Sensors6. SoC

Common issues:Integration/Unification, Standardization, Composability, Reuse


DES Roadmap – First Roadmap Synthesis (extract)

DES Roadmap DES Roadmap –– First Roadmap First Roadmap Synthesis (extract)Synthesis (extract)

Requirements, Specifications:ØUrgent need for methods and tools to capture ideas in models (analogy:

virtual reality modelling)ØKnowledge – base of re-usable parts and metrically quantified design

experienceResearch to resolve the specification problem of embedded systems by:ØRelating emerging system properties to individual system componentsØQuantitatively evaluating specification decisions based on specific

space metricsØObtaining specifications through iterative exploration of the

specification space




Requirements, Specifications:

Other issues:ØMethods and Tools for Design capturing at high system level with

specification debugging facilities, including HW/SW/reconfigurable partitioning([RM Embedded], App.4)ØMethods and Tools for enhancing reuse of requirements, modules, for

better understanding architecural choicesØMultidisciplinary training for requirements practitioners: social and

technical skills. ØNew techniques for formally modelling and analysing properties of the

environment, as opposed to the behaviour of the software: take into account the need to deal with inconsistent, incomplete, and evolving models; adaptation of products into product families




Architectures, Design:

ØShift between HW and SW, reconfigurable computing (flexibility). Tools for mapping parts to reconfigurable architectures, tools to do design space exploration in the three dimensions: HW, SW, and reconfigurable parts of the architecture.ØSystem Network connecting the system nodes: distributed

communication control, fault tolerance, SECURITY.ØSensor Network connecting system nodes to smart sensors and

actuators: multi-master networks for synchronisation – mobility: Dynamic reflective Systems !ØNeed for widely adopted Component Models and FrameworksØ Integration of proven Design Patterns




Architectures, Design:ØArchitectures that provide generic (as opposed to application specific)

services for fault tolerance, such as fault-tolerant clock synchronisation, or a membership service at the hardware or system software level. Ideally, the application software for a fault-tolerant system and a non-fault-tolerant system will be the same. ØSemantic Interface Specification (Interface Model, for HRT)ØDevelopment of architectures and software design methods that

support composability. ([RM Real-Time], Fault Tolerance)ØArchitecture Description languages ([RM SW-Intensive], Software

Engineering)Ø Integration frameworks for asynchronous applications, interactive

applications, synchronous applications, COTS componentsØDesign for Adaptive ES (QoS, resource aware, energy aware)[RM QoS],

separation of HRT and QoS Concerns




Realisation:ØCompilers and translators. Need for at least two kinds of compilers: First kind

is retargetable towards various hardware designs in order to deliver code efficiently executing on these designs. The second derives the hardware architecture from the behavioural specification based on several cost functions and simultaneously generates the software executable for this hardware [compiler decides on kind of implementation architecture].

Ø Lightweight formal methods: consistent methodology (not only case studies); lightweight approaches for safety analyses of evolving requirements, design revisions, and maintenance. ([RM SW Safety], Integration)Ø Integration of previously distinct formal methods. ([RM SW Safety],

Integration)ØHuman factors engineering: usage patterns (based on field studies), formal

specification of operator’s mental model, catalogue of past mistakes, list of design features prone to causing operator mode awareness errors – checklist for design and code inspection. ([RM SW Safety],




V & V:

ØDesign more user-friendly verification tools by separating the verification and validation functionality from the underlying mathematics. ([RM Embedded],Ø Problem of exploring very large state spaces in a manner that is

computationally efficient. Hierarchical design. ØUnification of hard- and software tests, validation and certification (certifiable

components to build certifiable systems !!), Safety Case AnalysisØRequirements-based testing: tighter integration of testing tools with

requirements analysis tools and improved test-case generation for safety-related scenarios to provide better links between safety requirements and test cases; better support of evolutionary development that uses exploratory programming as its process model, link between requirements and the overall system development in an unconventional development process, mechanisms for propagation of new safety requirements derived from testing of prototypes. ([RM SW Safety], Testing)




COTS, Sensors:ØStandardise sensorial interfaces ([RM Embedded], Interactions)ØStandardise API, architecture and external behaviour of IP components

([RM Embedded], hw/sw design)– Debugging facilities, Diagnosis (transient vs. permanent faults)– Intra component V&V– Inter component V&V (JTAG like)

ØComposability and reusability ([RM Real-Time], Introduction)ØTemporal interface specifications for Communication Network

Interfaces (CNI). ([RM Real-Time], COTS), Linkage Interfaces [TTA]ØCOTS: Empirical study on reliability risks - large user base;

characterise differences between usage environments and their effects on reliability; develop practices for documenting past reliability records that can become accepted standards. ([RM SW Dependability], Trends)




COTS, Sensors:ØSafe reuse of COTS software: certification, sufficient understanding of

system and environment (both original and target) to identify when software is used outside the “operational envelope” for which it was originally designed and tested; confirmation, that COTS does not other (unexpected) things as well (hierarchical verification via functional refinement may be inadequate, notions of architectural refinement may provide better verification). ([RM SW Safety], Constraints)ØSpecial: Neuromorphic Sensors/Components (Artificial Neural Systems)

– active vision– audition– motor control– central pattern generator– robotics




SoC:• For Systems-on-Chip migrate from bus-based communications toward

packet-switched networks-on-chip, with HW routers. ([RM Embedded], Platform)

• Power and cost models for design space exploration, also at highsystem level, taking non-functional constraints into account (complete system is implemented, but does not fit in the box). ([RM Embedded], App.4)

• New fault models will be required to handle crosstalk and new failure modes that will result from multi-level metal structures. The “stuck-at” single fault model is becoming less effective for computing expected test results for complex SoC fabrics. ([RM Semiconductors], Test for SoC)




SoC:• New test methods involving BIST are required that will allow low-speed,

low-cost ATE to test the digital portions of SoCs at high speed. ([RM Semiconductors], Test for SoC)

• Software-based fault localization tools compatible with major test methodologies such as SCAN, IDDQ, BIST, stuck-fault, AC test, dynamic logic, embedded cores. ([RM Semiconductors], Diagnostics, revolutionary)

• Hardware-based fault localization tools to complement and supplement the above. ([RM Semiconductors], Diagnostics, revolutionary)

• Signature analysis techniques to significantly reduce or eliminate the need for physical failure analysis. ([RM Semiconductors], Diagnostics, revolutionary)


DES Roadmap – Second Roadmap Synthesis

DES Roadmap DES Roadmap –– Second Roadmap Second Roadmap SynthesisSynthesis

Considerable exploitation and extension of the synthesis, chapters 4, 5, 6:

4. R&D Challenges important for dependability5. Research Needs of selected Application Domains

Since most Roadmaps are not application specific, additional sources have been used, especially workshop inputs and documents; additional to the 5 selected application domains, telecommunication and long – term research needs in this area have been taken into account

6. Research Agenda for Dependable Embedded SystemsA Matrix of Research Priorities for the selected Application Areas (Automotive, Aerospace, Rail, Industrial Automation, Medical and Telecom)was set up for each of 6 R&D areas (Requirements/Specifications, Architecture/Design, Realisation, V&V, COTS/Sensors, SoC).

Time scale: S(hort) (2 years), M(edium) (5 years), L(ong) term (> 5 years)

Reflects not only requirements and market, but also awareness !!!




Research Agenda concerning Requirements and Specifications:2003 2005 2008 2010ff

Elicitation5.2.3., 5.2.6.,5.7. Methods5.1.1, 5.1.2, 5.2.1., 5.2.3.,ffManagement5.2.3., 5.6.1.,5.6.2.,5.7.Validation5.2.1., 5.2.3.,5.6.1.,5.6.2.Training5.2.3., 5.6.1.Standardization5.2.1., 5.6.1.

AutomotiveAerospaceRailInd. AutomationMedicalTelecom





Research Agenda concerning Architecture and Design:2003 2005 2008 2010ff

Allocation5.1.1, 5.1.2,5.2.1,5.2.4ff Platform5.4.1,5.6.1Composability5.1.1,5.1.2,5.2.4,5.6.1,ffReconfigurability5.2.4,5.6.1.,5.7Interface5.7Communication5.7






Research Agenda concerning Architecture and Design (2):2003 2005 2008 2010ff

Methods, Tools5.1.1, 5.1.2,5.2.1,5.2.3ff Dependability5.1.2,5.2.4,6.6.1Middleware5.1.1,5.1.2,5.2.4,5.7Standardization5.2.1, 6.2






Research Agenda concerning Realization:2003 2005 2008 2010ff

Design Tools5.1.2,5.2.3,5.2.4,5.6.2,5.7 Formal Methods5.1.1,5.2.1,5.2.2,5.2.4,ffLanguages5.1.1, 5.2.2,5.4.1Compilers5.4.1Standardization5.2.1, 5.2.3






Research Agenda concerning V&V:2003 2005 2008 2010ff

Methods & Tools5.1.1,5.1.2,5.2.2,5.2.3,ff Formal Verification5.1.1,5.2.1,5.2.2,5.2.4,ffTesting5.1.1, 5.2.3,5.2.4,5.6.2Security5.1.2,5.2.4,5.6.2,5.7Standardization5.1.1,5.2.1,5.2.2,5.2.3,5.6.2






Research Agenda concerning COTS, SOUP and sensors:2003 2005 2008 2010ff

Certification5.1.1,5.2.1,5.2.2,5.4.1,5.7 Standardization5.1.1,5.2.1,5.2.2,5.4.1,5.7Methods5.1.1,5.2.2,5.4.1,5.6.2,5.7Dependability5.1.1,5.2.2,5.4.1,5.6.2,5.7






Research Agenda concerning SoC:2003 2005 2008 2010ff

Fault Models

Tools

Standards5.2.1Methods

Test




DES Roadmap Education and Training Issues

DES Roadmap DES Roadmap Education and Training IssuesEducation and Training Issues

Gaps identified [Workshops, IEEE/ACM-SEEK, ARTIST]:Ø Lack of qualified engineers able to develop ES (Traditional

Engineers learn on-the-job, application domain specific)Ø Broad (systems) perspective neededØ Knowledge on Dependability issues should be disseminatedØ Designers of ES do often not systematically consider

interdependencies between critical and non-critical (sub-) systems (air conditioning corrupts vehicle network, toilet control on general train bus corrupting critical functions)

Ø Need for Standardization and Knowledge of StandardsØ Confidential Design and commercial confidentially of incident

reports are barriers to a broad knowledge exchange




Required Skills for (Dependable) Embedded Systems Designer/ Engineerfrom three technical disciplines: computer science, electronics, control theory

Appreciation for multi-disciplinary nature of design– Both hardware & software skills– Understanding of engineering beyond digital logic– Ability to take a project from specification through production

Communication & teamwork skills– Work with other disciplines, manufacturing, marketing– Work with customers to understand the real problem being solved– Make a good presentation; even better -- write “trade rag” articles




And, by the way, technical skills too…– Low level: Microcontrollers, FPGA/ASIC, assembly language, A/D, D/A– High level: Object-oriented Design, C/C++, Real Time Operating

Systems, Distributed Systems– Dependable Middleware Knowledge (e.g. TTP/TTA)– Control- and signal processing– Meta level: Creative solutions to highly constrained problems– Dependability Assessment and Evaluation, Risk/Hazard Analysis,

Safety Case Analysis– Understanding Requirements – Requirements Capture– Understanding non-functional properties typical for ES: low power,

size, weight, dependability, performance, ….– Formal Methods Application– Likely in the future: Unified Modelling Language, embedded networks,

XML, (RT-) CORBA, Pattern Languages (Long term)….– Uncertain future: Java, Windows CE


DES Roadmap – EU Project AMSDDES Roadmap DES Roadmap –– EU Project AMSDEU Project AMSD

Roadmaps available at http://www.am-sd.org


DES Roadmap - ReferencesDES Roadmap DES Roadmap -- ReferencesReferences[ 1] ITEA – Technology Roadmap on Software Intensive Systems, ITEA Office

Association, Eindhoven, March 2001[ 2] Robert R. Schaller, Technology Roadmaps: Implications for Innovation,

Strategy, Policy. Ph.D. Dissertation Proposal, The Institute of Public Policy, George Mason University Fairfax, VA

[ 3] Alan Allen, Don Edenfield, William H. Joyner Jr., Andrew B. Kahng, Mike Rodgers, Yervant Zorian, 2001 Roadmap for Semiconductor Technology, in: IEEE Computer, January 2002, p. 42

[ 4] Gabriel Lean, Donal Hefferman, Expanding Automotive Electronic Systems, in: IEEE Computer, January 2002, p. 88

[ 5] Robert R. Schaller, Master Roadmap Bibliography, George Mason University, 1999

[ 6] US Office of Industrial Technologies, http://www.oit.doe.gov/[ 7] US Office of National Technology Transfer Centers,

http://www.nttc.edu/products/resources/technical/techroadmaps[ 8] International Technology Roadmap for Semiconductors (SIA, 1999),

http://public.itrs.net/files/1999_SIA_Roadmap/Home.htm/


DES Roadmap - ReferencesDES Roadmap DES Roadmap -- ReferencesReferences[ 9] Kostoff, R.N. (1997), Science and Technology Roadmaps, Defense Technical

Information Center, http://www.onr.navy.mil/sci_tech/ special/technowatch/docs/mapieee10.doc

[10] Max Lemke, DG INFOSO – C4, Roadmap Projects in IST Key Action II – New methods of Work and Electronic Commerce, 2002.

[11] W. Merker, The Vision of Accident Free Driving (presentation slides), DaimlerChrysler; http://www.daimlerchrysler.com/index_e.htm?/ specials/accidentfreedriving/afd1_e.htm

[12] Dieter Donhoffer, Erwin Schoitsch (Ed.). Proceedings of the Joint Workshop "Advanced Real Time Systems". Vienna, March 26, 2001.

[13] Anthony Finkelstein (Ed.) , The Future of Software Engineering, several articles on Software Engineering Roadmaps. July 2000 (ICSE 2000), publ. by ACM, ISBN 01-58113-253-0.

[14] Hansen, “The Hansen Report on Automotive Electronics, Vol 14, No. 5,” 2001. [15] ARTIST: http://www.systemes-critiques.org/ARTIST/ - Roadmaps Drafts May 2003[16] ECUA: Final Techn. Report; High Integrity Systems SIG Report (2002) [17] Embedded Systems Roadmap 2002, Ludwig D.G. Eggermont (ed.), STW


DES Roadmap – Additional SourcesDES Roadmap DES Roadmap –– Additional SourcesAdditional Sources[18] “IT-Forschung 2006: Föderprogramm Informations- und

Kommunikationstechnik”, Bundesministerium für Bildung und Forschung (BMBF), Bonn, März 2002 (German National ICT Research Programme IT 2006)

[19] Philip Koopman, „Embedded Systems in the real World“, 1999[20] VDC 2002: “The Embedded Software Strategic Market Intelligence Program

2001/2002. Volume IV: Embedded Operating Systems, Software Development Tools, Design Automation Tools and Test Automation Tools”.

[21] H. Kopetz, Research issues in Dependable Embedded Systems, IFIP WG 10.4, Jan. 2002

[22] E. Schoitsch, Report from the AMSD-ARTIST Joint Workshop, Oct. 3, 2002, Grenoble, AMSD Delivery D 3.2. DES.

[23] ARTIST Industrial Seminar “Roadmap for European R&D in the 6th PCRD”, April 23rd, 2002 – Hard Real-Time Systems/ Component-based Design and Development (http://www.systemes-crtiques.org/ARTIST/ (past events)

[24] Lars Stranden, Johan Hedberg, Hakan Sivencrona, SP “Machine Control via Internet – a holistic Approach”. SP-Electronics Report 2002:30


DES Roadmap – Additional SourcesDES Roadmap DES Roadmap –– Additional SourcesAdditional Sources

[25] EWICS TC7 Workshops (European Workshop on Industrial Computer Systems, TC 7, Safety, Reliability and Security.

[26] EWICS TC7, Rail Subgroup, recent and ongoing work[27] EWICS TC7, Medical Devices Subgroup, recent and ongoing work[28] F. Pilarski, Safety Critical Embedded Systems – Orientations for the Future;

presentation at the IST Conference 2002, Copenhagen, November 6, 2002[29] Proceedings of the Joint Workshop Advanced real-Time Systems, D. Donhoffer,

E. Schoitsch (Eds.), Vienna, March 26, 2001, ISBN 3-9500255-9-6.[30] FIT – IT, Austrian Research Programme “Embedded Systems”, A. Ferscha, 2001.[31] ERCIM – European Research Consortium in Informatics and Mathematics, WG on

Dependable Software-intensive Embedded Systems, ongoing work (ERCIM News 52, Jan. 2003, Special Issue “Embedded Systems”).

[32] UK's Science and Technology Road-Mapping Project “Foresight Futures 2020” (Avionics, general scenarios), http://www.foresight.gov.uk/

[33] eSafety – Final report of the eSafety WG on Road Safety, EC–IST DG, Nov. 2002[34] IEEE/ACM SEEK - Software Engineering Education Knowledge Report, Dec. 2002

EmSys Summer School University of Salzburg, 2003 Embedded ... · Adelard ARCS CNUCE JRC LAAS...

Documents

Transcript of EmSys Summer School University of Salzburg, 2003 Embedded ... · Adelard ARCS CNUCE JRC LAAS...