HTSM 2012 Roadmap Embedded Systems

Transcription

1 HTSM 2012 Roadmap Embedded Systems Version 1.0. November 14, 2012: Roadmap team Hans Geelen, Océ Boudewijn Haverkort, ESI & UT Erik Peeters, TNO NWO/STW representatives Margriet Jansz, STW Robert van der Drift, NWO Author/Editor Boudewijn Haverkort, Embedded Systems Institute: Contributors This roadmap has been composed in the period September-November 2012 by a large number of R&D staff of Dutch academia and industry, on the basis of the Embedded Systems roadmap A complete list of all contributors is provided in Appendix B, and a process description is provided in Section 4. Background documentation This roadmap consists next to the main text, of a number of appendices. The complete roadmap, including the appendices, can be found on the website HTSM (

2 HTSM roadmap for Embedded Systems Laying the foundation for dependable and adaptable intelligent high-tech systems Embedded Systems are integrated hardware/software systems built into devices that are not necessarily recognized as computerized devices or computers, however, these embedded systems do control and actually define the functionality and quality of these devices. Embedded systems are typically not monolithic, but consist of multiple processing units, connected through wired or wireless networks. The size of the system components ranges from tiny battery-powered intelligent sensors and actuators, to large multiple-rack computing devices. The key concern for embedded systems is that they have to fulfill a wide variety of strict resource constraints, ranging from limited energy-usage, memory-footprint and limited processing power to space and weight constraints. At the same time, they have to fulfill strict requirements regarding performance and reliability (dependability). The limited resources and strict extra-functional requirements distinguish embedded systems from ICT systems in general. The design of embedded systems is intrinsically a multidisciplinary activity, requiring skills from computer science, electronics and mechatronics and control, next to a thorough understanding of and interaction with the application field, that is, often the physical world (leading to, what is now often called, cyber-physical systems). Please refer to the appendices for more information on Embedded Systems. 2

3 1. Societal end economic relevance Embedded systems do form the core of the functionality and intelligence in almost all technical solutions for: - A safe, secure and comfortable environment; - Fast and flexible transport infrastructures and transport means, e.g., cars, connected cars, or aircraft, for both people and goods; - Advanced systems for leisure and lifestyle, such as game consoles, home automation, tv-camera s, etc.; - Cost effective and efficient healthcare and well-being; - Dependable and secure (tele-) communications; - Cost-effective healthy food production; - A sustainable and clean environment, including the efficient use of water, fossil and mineral resources. As such, embedded systems play a key role in society, albeit most often in an invisible way. The above societal needs are also addressed, from an application perspective, in the application-oriented roadmaps for HTSM, among others in the roadmaps for security, automotive, aerospace and healthcare. Next to that, embedded systems are core technology for a number of application fields that address societal needs only in an indirect way, but nevertheless are of key importance in the topsector HTSM: examples include semiconductor equipment, printing, lighting and solar (where the latter three do address sustainability and energy needs) and, finally, components and circuits. All these roadmaps, comprising the overall HTSM roadmap, clearly state the need for core embedded systems technology. Next to that, also in other topsectors, embedded systems will be used, e.g., in the top-sectors logistics or energy. The separate cross-domain ICT roadmap will address the relevance of ICT for all topsectors, thereby addressing also embedded systems (among other, under the heading ICT for monitoring and control ). The size of the Dutch embedded systems market is difficult to measure as such, as embedded systems are inherent part of a wide variety of high-tech products. The turnover in the field of high-tech products in the Netherlands is estimated at 73 B /yr, and has shown the highest growth levels of all topsectors. Although not the largest in size, the high-tech systems market is among the largest in terms of export value in the Netherlands (about 32 B /yr). The public R&D investment amounts to 2.2 B in 2009, and will rise to 3.5 B in 2020, According to the Artemis embedded systems roadmap, embedded system technologies form the fastest growing sector in Information Technology. Apart from the abovementioned application fields, the high-tech embedded systems field does contribute to the efficient use of resources, as it generally aims at increasing the level of intelligence of the machines being produced, thus resulting in equipment that has a low carbon footprint or machines that produce other goods with less waste. 3

4 2. Application and technology challenges This section has been written such that a line of reasoning from technology trends (Section 2.1), via high-tech product challenges (Section 2.2) and common technology challenges (Section 2.3), to an integrated set of scientific challenges (Section 2.4) is derived. The scientific challenges in Section 2.4 are aligned along four axes: system architecting (2.4.A), system design (Section 2.4.B), system integration and test (Section 2.4.C) and model-driven design and tooling (Section 2.4.D). Hence, our program can be considered of consisting of these four research lines, thereby addressing four industrial system-level challenges, related to system performance and dependability, system evolvability, system context-awareness, and system implementation techniques. 2.1 Technology trends (cf. Figure 1) With rising processing capability of computer hardware, such as higher clock rates, multicores and increasing storage capacity, but also increasing presence of additional functionality (sensors, actuators), embedded systems capabilities will keep rising. There will be more and more software in embedded systems, and these systems will increasingly be integrated into networks, resulting in specific new challenges in the fields of interconnectivity and data security. A myriad of new functions will come out of these trends. Large scale networks of intelligent embedded systems will be more common, that will increasingly be adaptive to their environments, without any central control. Furthermore, the functionality of embedded systems is becoming more and more dependent upon the interaction with other (embedded) systems, in which also real-time imaging (or even vision) systems do often play an important role. Embedded systems are mostly heterogeneous and complex. Since they are mixtures of hardware and software, trade-offs are important: when designing a product that encompasses an embedded system, a first question is whether one does accomplish certain functionality in computer hardware or in software. In addition many other trade-offs do play a role, e.g., between energy consumption, performance, adaptivity, dependability, space and weight, or cost. Furthermore, to satisfy the extra-functional constraints under severe resource limitations, often specialized hardware, e.g., FPGA s, specialized signal processing, is needed. The design of such specialized hardware components, as integral part of an overall dedicated system, adds to the overall design complexity. The area of embedded systems is a multidisciplinary field with an important integrating role for software. It is also a field in which a wide diversity of modelling formalisms, such as differential equations, failure models, power, heat dissipation and timing models, must be reconciled with the discrete behavioral models (state-transition systems, data flow models) underlying software systems. Embedded systems also pose significant integration challenges. By means of software, subsystems are being integrated into complete systems delivering the right functionality, at the right cost and with an adequate performance and dependability. This task of integrating, as well as the task of distributing requirements over the subsystems, is a discipline by itself system integration that is still in its infancy. A further important development is so-called early integration, where realized components are integrated with models of not-yet realized components, and tested. 4

5 systems-ofsystems user expectations data-intensive operations mixed-criticality openness connectedness interaction with physical context high-tech embedded systems parallel & multicore systems HW variability & unreliability autonomous operation third party components Figure 1: Key technology trends making embedded systems design an ever-growing challenge To be able to design and build embedded systems, for the wide variety of system types, all with different requirements, sets severe challenges to the field, both for products and the common technology. 2.2 High-tech product challenges For high-tech companies, the key challenges can be grouped into those at strategic level, at the level of processes, and at system level. The strategic challenges include to stay abreast of innovative new technology (or to be a creator of that) and to incorporate this new technology, next to third-party components, into products finding their way to the market. This requires the right timing and pricing, and the acceptance of the technology (and product) by society. The process challenges include the production processes for high-tech embedded systems to be flexible, right-first-time, and yet be able to deal with the complexity at hand. This includes the challenge to deal with high-level state-of-the-art tooling (and beyond), but also to integrate tooling from various disciplines and from various subsystem suppliers. Figure 2 (below) illustrates the importance of methods and tools; having developed state of the art methods and tools, product development processes can be improved, leading to both better product quality, and reduced cost (and time) in the actual product development process. The current roadmap very much focuses on the improvement of the product development process through better methods and techniques; indirectly, in industry, this will lead to better products (see the system-level challenges below). Figure 2: Relation between product development, the product development process, and the availability of adequate methods and tools 5

6 The system-level challenges in essence address the issue of making better, higher-quality systems. More concretely, they address the ability to 1) design and implement systems that support key system qualities, most notably performance and dependability (reliability, availability), but, depending on the application, also energy usage, security, privacy, and scalability; 2) design and implement systems that are evolvable and adaptable, that are able to change their function over time, with or without manual intervention, modular and x- wards compatibility, or are platform-based, or comprise product families, all to achieve proper cost-benefit; these systems should be future proof; 3) design and implement systems that are interoperable and may function in a yet partly unknown ubiquitous computing setting, and are self-organizing ( plug-and-play ) in a context that is not a priori set; we refer to this as context-aware systems; 4) implement systems on a variety of hard- and software platforms; this includes methods and techniques for code generation and systems programming, taking into account resource constraints (see also 1) above). 2.3 Common technology challenges The common technology challenges for all classes of embedded systems (cf. Appendix A) can easily be described with the help of the classical V-model for systems design, extended here to also include (the usual) feedback and iteration cycles (cf. Figure 3). For specific classes, specific aspects may need to be emphasized. Furthermore, by the use of model-based techniques (see below) an iterative design process is enabled, allowing shorter design cycles instead of costly redesigns, or avoid costly prototyping phases. Figure 3: The classical V-model for (embedded) system design The design process creates, starting from system requirements, step-by-step the concrete system components, thereby carefully taking into account the trade-offs between various desirable system properties (or qualities), such as performance, dependability, adaptability, energy-usage, etc. Key challenges here include the use (and integration) of the right models and tools to guide design steps, as well as tools and techniques for code management and generation (for heterogeneous platforms). A final step of the design comprises the 6

7 programming and scheduling of hardware components (CPU s, GPU s, multicores), as well as the design of specialized hardware, e.g., SOC s, FPGA s. This includes methods to program large-scale systems, e.g., wireless sensor systems with thousands of nodes, and methods to implement functionality in various forms of hardware. Following the design is the very challenging process of system integration and testing. Key challenge here is to make this process more systematic and less costly; in current practice, well over 50% of system development costs are spent in this phase. Furthermore, dynamic integration is a new and important issue, especially for systems of systems and very-large evolving systems. Model-based design (see below) can help in making this last phase shorter and more efficient, by making the design phase more rigorous. Both the design and the integration phase will heavily profit from a sound model-based fundament. The development of methods and techniques for model-based design and model-based integration and test, plus the development of powerful tools to support these methods, is an important supporting challenge. Model-based design decreases development time and cost, avoids lengthy prototyping phases, shortens the implementation and test phase, and increases the overall quality. Finally, to provide overall guidance in the system design and integration process, to develop a framework for trade-off analysis, and to make sure systems are developed that have the functionality as desired, a sound architectural basis is required. These are generally referred to as methods and techniques for (embedded) system architecting. The overall picture is illustrated in Figure 4. Figure 4: Relation between system-level challenges (cf. Section 2.2) and scientific challenges (cf. Section 2.4) 2.4 Scientific challenges The scientific challenges can be clustered along the four technology challenges (as above). 7

8 A. System architecting defines stable high-level system structures that are consistent with the requirements of the stakeholders. It encompasses requirements capturing, trade-off analysis, key technology choices, system partitioning, high-level budgeting, cost/benefit analysis, and assessment of system qualities, e.g., behaviour, performance, reliability, evolvability, and cost. Research on system architecting addresses two main challenges: 1. The development of architectures themselves. This includes: The codification of existing solutions in terms of best practices or reference architectures, generically, or for specialized classes of systems, e.g., architectures for data-intensive systems, or for real-time systems; Finding solutions under new and advanced requirements, e.g., in the context of systems of systems, or for systems with mixed criticality; High-level trade-off regarding hardware and software; Incorporating legacy and third party components and (sub-) systems. 2. Methods and techniques to develop and evaluate architectures. They must provide guidance in the following activities: Clarification of unclear requirements based on stakeholder concerns, as well as dealing with uncertainties regarding future changes in the requirements, or application context. Assessing and optimizing evolvability while avoiding architecture degradation over time. System architecting in a multidisciplinary context, where the various disciplines involved use different concepts, languages, and ways of working. Quantifying the various quality aspects of a system, as shaped by the architecture, and finding an acceptable or even optimal combination of different quality aspects (including all kinds of validation techniques). Documenting the architectural solutions and communicating them to the various stakeholders. B. System design refines high-level system architectures by decomposing them into smaller components. Further refinements lead to fine-grained structures which finally lead to system realization. This requires many design decisions, covering multiple disciplines. Here, explicit attention is paid to carefully trade-off extra-functional concerns regarding performance, reliability, evolvability, resource usage, energy usage, and costs. Furthermore, actual implementation strategies for (large-scale) systems need further development: 1. An important challenge during the design process is the difficulty to assess design alternatives and the impact of design choices on product cost and quality, because: Multiple disciplines are involved, typically mechanical, electrical, optical, and software engineering together with some domain specific disciplines such as magnetic resonance, ink-jet technology, electromagnetic lenses technology, etc. Multiple aspects have to be balanced, such as costs, performance, energy consumption, heat dissipation and the amount of code reuse. Early in the design process the most important decisions have to be taken although many aspects are still uncertain, especially concerning extra-functional aspects such as resource usage and performance. Embedded systems are developing into open and dynamic systems, which means that the system has to be designed such as to deal with many different environments and should be prepared for future changes. 2. The current state-of-the-art techniques do not provide sufficient support: 8

9 They are often either too coarse (spreadsheet-type analysis) or too detailed (implementation level, full functionality prototyping) to allow for extensive, multi-objective design-space exploration. They are insufficiently tailored to users from different application domains and to multi-disciplinary use. They do not cope well with openness and dynamic, adaptive systems. Relationships between models of different disciplines are usually unclear. 3. Techniques for system implementation. This encompasses a wide variety of techniques addressing software and hardware implementation: The use of software engineering and programming techniques to generate efficient yet maintainable code, that can be deployed on a large scale, for a variety of hardware devices; The generation of code for resource-constrained devices (e.g., regarding memory, processing power or energy); Techniques to deal with an increasing degree of parallelism (e.g., in multi-core CPU s or on FPGA s); Hardware and software co-design. C. System integration and test. After repeated decomposition and refinement during the design phase, realized components are to be combined and integrated progressively until the complete system is obtained. Between these integration steps, the resulting parts and subsystems are tested to check their quality and compliance with the requirements, both functionally and extra-functionally. Integration is a very costly part of system development (up to 50%), and is frequently hampered by incomplete and ambiguous component specifications, unclear dependencies between components, and (subsequent) late detection of faults. Integration is also often considered to be a management problem, and it is approached that way. Testing is still a mainly manual hence expensive and error-prone process. The necessary test effort tends to grow faster than the growth of system complexity and size. With the trends towards open systems and systems-of-systems, system integration and testing is shifted in part to the operational phase, thus exacerbating the problem and leading to the need for runtime testing and integration. The key challenge is to make the integration and test process faster, more manageable, and better predictable with respect to the process (time, effort) as well as the product (quality). This implies the need to increase awareness about the importance of the testing and integration process, and the necessity to provide a more profound scientific and technological basis. More specifically, the challenges include: The detection of potential integration problems early when they are not yet (too) expensive to be repaired. The construction of components and interfaces that fit together the first time. The reduction of manual effort in testing. The reduction of the time for finding the root cause of a failure, i.e., faster and better diagnosis. The development of systems and components that are meant for integration and testing, i.e., how can systems be architected, designed, and implemented that are more easily integrated and tested. System integration is a very important attention point in the system design and decomposition phase. 9

10 The development of methods and techniques for hardware/software co-testing and hardware/software co-integration. Moreover, the product and technology challenges identified for high-tech embedded systems (cf. Figure 1) aggravate these challenges. A system-of-systems requires integration and testing to be performed in a dynamic and online context, without having full control over all the systems comprising the system-of-systems. Multi-disciplinary system design asks for combinations of physical (hardware) and software testing methods. Variability implies the need for good selection methods so that enough but not too many variations are tested. Increased expectations with respect to extra-functional quality characteristics require new and efficient testing methods: decomposition and integration are currently largely driven by functionality, however, extra-functional quality characteristics must be taken into account during decomposition and integration. D. Model-driven design and tooling. More and more, we see the use of models throughout the complete development process. This requires appropriate methodological and tool support. Many modelling techniques exist for many different purposes, e.g., functional flow, thermal analysis, performance, power consumption, test generation, communication, code generation, documentation, etc. These models are made at different time points during development and with different methods and tools. Often models are not well maintained during development. Thus, models typically have unclear relations to each other and to the eventually realized system. This leads to inconsistencies, duplication, and confusion. Communication between designers and between disciplines is often difficult, as different parameters are being modelled and different languages are being used. In addition, it is often unclear which modelling methods are best suited, how to make proper modelling abstractions, and how to do this efficiently. 1. A first set of questions relates to the use of models throughout the entire system design process, from the very early stages of requirements capturing to system integration, system test, and system evolution, as follows: How to manage many different models? How to relate these models, how to maintain them, and how to guard their consistency? How to capture and trace design decisions? Which models are cost effective in which phases of the design and development process? What are solid business cases for the use of model-based techniques? How to obtain sufficient evidence for that? 2. A second set of scientific challenges, relates to the type of models being used, in particular, to the required classes of models and analysis techniques, such as to really support the design process in view of the technology trends (cf. Figure 2): How to deal with different types of models (discrete, continuous, and stochastic)? How to systematically combine and use different types of models (multi-domain) and predictions? How to cope with the complexity of today s embedded systems? How to improve scalability of model analysis and model-based synthesis methods? How to support modular design and compositional reasoning? How to cope with the increasingly dynamic nature of embedded systems? The field of model-driven design and tooling is never a goal in itself; key issue is that the tools and techniques that are developed need to answer questions that do exist in the design process. 10

11 3. Priorities and programs A mixture of fundamental and applied R&D activities is proposed, with sourcing from industry, NWO/STW and TNO. We aim for activities with NWO funding (largely to be executed by academic partners), with STW funding (to be executed by academic partners in cooperation with industry and institutes such as TNO, ESI and INCAS3), as well as activities that are more applied. An important priority for the years to come is the inbedding of ESI in the TNO organisation, starting January 1, The TKI-funding obtained through industrial in-cash contributions to ESI, will be used to strengthen the ESI program. The projects that will be executed in 2013 and that apply for TKI will (grondslag TKI), as well as the extra projects that will be executed using the TKI (inzet TKI), will be described in two separate sets of documents ( Grondslag TKI HTSM-ES en Inzet TKI HTSM-ES ; both as Excel sheet and as short description). All these projects will be in line with the roadmap. Part of the program will be implemented as part of Itea2, Artemis, FP7 (or its successor H2020) European funding programs. It is of utmost importance to be able to internationally anchor the ES activities; the ES field is an international playing field, with strong industrial and academic players in countries like, among others, Germany, France, Sweden and Switzerland. European programs provide an excellent opportunity to firmly connect to and cooperate in these international developments. From within the roadmap team, we strive to bring the important topics of this roadmap on the agenda of the above mentioned European programs. The key players in the Dutch Embedded Systems field have very good contacts in the appropriate European program offices. 11

12 4. Partners and process Process. The HTSM 2012 Roadmap for Embedded Systems has been developed in close cooperation with the academic and industrial R&D community for embedded systems in the Netherlands. Starting point has been the 2011 roadmap (the process towards that roadmap has been described in Appendix F of that roadmap). In the fall of 2012, a number of extensions have been proposed as compared to the 2011 roadmap. These have been put forward to the klankbordgroep (cf. Appendix B). All reactions received have been carefully addressed and incorporated as good as possible. Partners. Key partners include TNO, ESI, the 3 TU s, INCAS3 and key high-tech companies in the Netherlands, including ASML, Océ, NXP, Philips, Vanderlande Industries, FEI Company, Vodafone, Ericsson, etc. Next to these large OEMs, also SMEs are strongly involved in the HTSM/ES project portfolio, with companies like Recore Systems, CHESS, OTB, Assembleon, Compaan, Ambient Systems, Controllab Products, Grass Valley and Sioux Technologies BV. 12

13 5. Investments The overall investment in the public-private R&D as described in this roadmap is summarized in the following tables; all figures are in M per year. Roadmap program Industry TNO NLR NWO Incl STW, ZonMW, FOM, etc Universities EC EL&I Other institutes Other government incl regional, etc Grand total Incl imec, non-nl universities, etc TKI program Industry, cash Industry, in-kind TNO NLR NWO Incl STW, FOM, ZonMW, etc Universities Other institutes Incl imec, non-nl universities, etc Other government Incl regional, etc TKI grant TKI total European program Industry TNO NLR FOM Universities Other EU total, projects Incl imec, etc EC EL&I Other EU total, grants

14 Appendices to the HTSM Embedded Systems roadmap A. What are Embedded Systems? Embedded Systems are integrated hardware/software systems built into devices that are not necessarily recognized as computerized devices or computers, however, these embedded systems do control and actually define the functionality and quality of these devices. Embedded systems are typically not monolithic, but consist of multiple processing units, connected through wired or wireless networks. The size of the system components ranges from tiny battery-powered intelligent sensors and actuators, to large multiple-rack computing devices. Key concern for embedded systems is that they have to fulfill a wide variety of strict resource constraints, ranging from limited energy-usage, memory-footprint and limited processing power to space and weight constraints. At the same time, they have to fulfill strict requirements regarding performance and dependability. The limited resources and strict extra-functional requirements distinguish embedded systems from ICT systems in general. The design of embedded systems is (therefore) intrinsically a multi-disciplinary activity, requiring skills from computer science, electronics and mechatronics and control, next to a thorough understanding of and interaction with the application field. Embedded systems form the intelligent core of an ever-increasing share of high-tech systems. The high-tech system market is a world market, with extremely high competitiveness, requiring the right products to be developed and introduced at very high pace, for very competitive prices. Industry does invest intensively to keep or even improve its market share. The market is also characterized by intimate relationships between OEM s and a chain of suppliers (often SME s). To keep this chain of innovation operational, an open collaborative, entrepreneurial and research attitude is required and needs to be maintained, next to a supply of highly qualified and skilled people. The term embedded systems encompasses a wealth of different systems, with highly different characteristics and demands. The R&D work required to come to better systems, does need to be tailored to the specific characteristics at stake. Pervasive systems (also called ubiquitous systems) extend the vision of ambient intelligence to that of fully embedded and flexible networked ambient systems (with wireless sensor systems often playing a key role) that provide easily accessible yet unobtrusive support for a range of activities. We find such systems in healthcare and wellbeing, but also in transport, logistics, energy exploration, production and transport, as well as in security systems. Important issues are wireless technology, transparency, scalability, adaptability and evolvability (that is, the ability to evolve or adapt systems to future needs over longer time spans), distributed architectures, and the trade-off between local processing and communication. Consumer systems are used in homes, cars, on-body and in offices, e.g., used in healthcare and wellbeing and for lifestyle and leisure. Due to high competition in these application fields, short time-to-market and low cost are equally important. Important issues are reuse of components, flexibility and energy consumption (hand-held phones and PDA s). Robotic systems are currently evolving from the sturdy industrial robots to the more interactive service robots supporting humans in daily life. Their functionality extends to more autonomous behavior, as they have to deal with physical interaction with the environment. The embedded software governing such robots becomes increasingly 14

15 important, due to more prominent functionality as autonomous reasoning (e.g., to obey safety rules, or to interact with the environment) these robots have to do to fulfill their tasks. Application areas are besides the classical automation of production processes (in e.g. producing vehicles), robot-assisted surgery, robot-assisted revalidation, robotic assistance for routine activities (such as vacuum cleaners, lawn mowers, robotic harvesters). Industrial or professional systems are those large and complex systems, as can be found in medical imaging, the semiconductor industry, industrial printing, scientific infrastructures such as SKA, and the food industry. Specialized classes, with increased focus on safety and dependability, are formed by automotive systems, avionics and space systems, and defense systems. Also to be mentioned here are mostly hidden integrated supervisory control and data acquisition (SCADA) systems, as used in large industrial plants, e.g., for energy and steel production, chemical plants, factory automation systems of all sorts. Professional imaging systems are systems that either provide high-quality images to the end-user, e.g., television cameras, security cameras, or capture and analyze images in realtime to derive data and/or control signals for a larger encompassing system. A key characteristic is that the quality of the imaging system sets the limits of the capabilities of the overall system. Professional imaging systems can typically be found in healthcare and well-being, lifestyle and leisure, industrial processes, and security and automotive systems. Public infrastructure systems include major intelligence support for infrastructures such as airports, cities and highways, and are used for a more efficiently and secure use of energy and power, transport, logistics and public spaces. Figure A.1 shows how these various classes of systems (partly coinciding with the topsector application roadmap themes) score on criteria related to market and lifetime. The diversity shows why tailored R&D is necessary for these systems classes but also identifies that synergy exists between classes that validates a generic approach next to an application approach on embedded systems R&D; indeed, Section 2 of this roadmap stresses the crossapplication core technologies required for embedded system design. Figure A.1: Classes of systems and their score on crucial market and lifetime parameters 15

16 B. Contributors to this roadmap Roadmap core team Anton Schaaf, Océ (boegbeeld ) Hans Geelen, Océ (boegbeeld ) Erik Peeters, TNO Boudewijn Haverkort, Embedded Systems Institute (editor) NWO/STW representatives Margriet jansz, STW Robert van der Drift, NWO Roadmap input ( klankbordgroep ) Adriaan Aalbert, Pierre America, ESI Twan Basten, ESI & TU/e Frans Beenker, ESI Ronald Begeer, Philips Koen Bertels, TU Delft Albert-Jan Boonstra, ASTRON Paul van den Bosch, TU/e Jan Broenink, University of Twente Henk Corporaal, TU/e John Coumans, Philips Jan van Dalfsen, TU/e Klaas Jan Damstra, Grass Valley Arie van Deursen, TU Delft Lex van Gijsel, Devlab Maurice Heemels, TU/e Marc Herregods, Philips Jochem Herrmann, Adimec Jozef Hooman, ESI & RU Nijmegen Maurice Houtsma, Thales Cees van Huet, ASML George Jentjens, Jentjens Edwin van Kalkeren, Vodafone Henk Koopmans, Sensor Universe Wido Kruijtzer, Synopsys Wouter Leibbrandt, NXP Johan Lukkien, TU/e Peter Manolescue, Vodafone Marc van Mierlo, Van Mierlo Wim Pasman, Philips Eddy Pijpers, LNR Andy Pimentel, Universiteit van Amsterdam John van Pol, Incas3 Ger Schoeber, Hotraco Guus Schreiber, VU Amsterdam Gerard Smit, U Twente Lou Somers, Océ Jan Tretmans, ESI & RU Nijmegen Wolfgang Tostmann, AgentschapNL Frits Vaandrager, RU Nijmegen Marcel Verhoef, Chess Xander Vissering, KPN 16

17 Bernard van Vlimmeren, FEI Company Bruno van Wijngaarden, Vanderlande Industries Heinrich Wörtche, Incas3 17

18 C. Top-level reasoning for the HTSM/ES roadmap 18

19 D. Background reading D.1 International roadmaps and agendas The HTSM Embedded Systems roadmap aligns very well with a number of international Embedded Systems roadmaps and vision documents. The Artemis Industry Association Strategic Research Agenda, The German Nationale Roadmap Embedded Systems, Zentralverband Elektrotechnik und Elektronikindustrie, Kompetenzzentrum Embedded Software & Systems, December USA Common Computing Consortium Cyber-Physical Systems roadmap. Research Roadmap on Cooperating Objects, CoNET consortium, Hipeac roadmap: high-performance embedded architecture and compilation ITEA Roadmap for Software-Intensive Systems & Services, Ultra-Large-Scale Systems: The software challenge of the future. Software Engineering Institute, Carnegie Mellon University, Boston Consulting Group. The growing importance of embedded software, International Policy Conference on Strategies for Embedded Computing Research. March 18-19, 2010, Vienna. Strategy Report on Research Infrastructures, Roadmap 2010, European Strategy Forum on Research Infrastructures (ESFRI), European Union, March 2011, D.2 National roadmaps and agendas A number of national (embedded systems) roadmaps and vision documents have been consulted to write this roadmap. The 2010 Point-One Emerging Technology Agenda for Embedded Systems, Annual Plan, February 2011; The Strategic Research and Innovation Agenda of the IIP Vitale ICT; The Strategic Research and Innovation Agenda for the IIP Roboned; The Strategic Research and Innovation Agenda of the IIP Sensor Networks, Draft Strategic Research and Innovation Agenda, Embedded Systems Institute, September D.3 Selection of consulted scientific papers C. Baier, B.R. Haverkort, H. Hermanns, J.-P. Katoen. Performance evaluation and model checking join forces. Communications of the ACM 53(9): 76-85, September J.S. Fitzgerald, P.G. Larsen, K.G. Pierce, M.H.G. Verhoef, S. Wolff. Collaborative Modelling and Co-simulation in the Development of Dependable Embedded Systems. Lecture Notes in Computer Science 6396,

20 S.H. Fuller, L.I. Millet. Computer Performance: Game Over or Next Level? IEEE Computer 44(1): 31-38, January B.R. Haverkort. Formal Modeling and Analysis of Timed Systems: Technology Push or Market Pull? Proceedings FORMATS 2011, LNCS 6916: 18-24, September T.A. Henzinger, J. Sifakis. The discipline of embedded system design. IEEE Computer, October 2007: J.A. Stankovic. Strategic directions in real-time and embedded systems. ACM Computing Surveys 28(4): J.A. Stankovic, I. Lee, A. Mok, R. Rajkumar. Opportunities and obligations for physical computing systems. IEEE Computer, November 2005: R. Valerdi and 11 more authors. A research agenda for systems of systems architecting. International Journal of Systems of Systems Engineering 1(1/2): ,