340 likes | 545 Vues
Ultra-Large-Scale (ULS) Cyber-Physical Systems & Their Impact on Technology & Society. Dr. Douglas C. Schmidt Deputy Director, Research & Chief Technology Officer ARTEMIS Conference Linz, Austria, June 29 th , 2011. Evolution in Distributed Real-time & Embedded Systems. The Past.
E N D
Ultra-Large-Scale (ULS) Cyber-Physical Systems & Their Impact on Technology & Society Dr. Douglas C. Schmidt Deputy Director, Research & Chief Technology Officer ARTEMIS Conference Linz, Austria, June 29th, 2011
Evolution in Distributed Real-time & Embedded Systems The Past The Present • Standalone real-time & embedded systems • Stringent quality of service (QoS) demands • e.g., latency, jitter, footprint • Resource constrained • Distributed real-time & embedded (DRE) systems • Net-centric systems-of-systems • Stringent simultaneousQoS demands • e.g., dependability, security, scalability, etc. • More fluid environments & requirements This talk focuses on the past, present, & future of enhancing DRE system QoS, producibility, & quality
Evolution of DRE Systems Development CLI SM CM SS7 IP RX TX RTOS Consequence: Small changes to legacy software often have big (negative) impact on DRE system QoS & producibility • Technology Problems • Legacy DRE systems often tend to be: • Stovepiped • Proprietary • Brittle & non-adaptive • Expensive • Vulnerable Air Frame Nav HUD AP FLIR GPS IFF Cyclic Exec • Mission-critical DRE systems have historically been built directly atop hardware, which is • Tedious • Error-prone • Costly over lifecycles
Evolution of DRE Systems Development DRE Applications DRE Applications Middleware Services Middleware Services Middleware Middleware Operating Sys & Protocols Operating Sys & Protocols Hardware & Networks Hardware & Networks • Technology Problems • Legacy DRE systems often tend to be: • Stovepiped • Proprietary • Brittle & non-adaptive • Expensive • Vulnerable • Middleware has effectively factored out many reusable services from traditional DRE application responsibility • Middleware is essential for product-line architectures • Optimized middleware is no longer the primary DRE system performance bottleneck • Mission-critical DRE systems historically have been built directly atop hardware, which is • Tedious • Error-prone • Costly over lifecycles
Evolution of DRE Systems Development DRE Applications DRE Applications Middleware Services Middleware Services Middleware Middleware Operating Sys & Protocols Operating Sys & Protocols Hardware & Networks Hardware & Networks • Technology Problems • Legacy DRE systems often tend to be: • Stovepiped • Proprietary • Brittle & non-adaptive • Expensive • Vulnerable • Middleware has effectively factored out many reusable services from traditional DRE application responsibility • Middleware is essential for product-line architectures • Optimized middleware is no longer the primary DRE system performance bottleneck • Mission-critical DRE systems historically have been built directly atop hardware, which is • Tedious • Error-prone • Costly over lifecycles
& OS Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Operating Systems & Protocols The Evolution of Middleware Historically, mission-critical DRE apps were built directly atop hardware DRE Applications • Tedious, error-prone, & costly over lifecycles There are layers of middleware, just like there are layers of networking protocols • Standards-based COTS DRE middleware helps: • Control end-to-end resources & QoS • Leverage hardware & software technology advances • Evolve to new environments & requirements • Provide a wide array of reusable, off-the-shelf developer-oriented services Hardware Middleware is pervasive in enterprise domain & is becoming pervasive in DRE domain
Examples • Java Virtual Machine (JVM), Common Language Runtime (CLR), ADAPTIVE Communication Environment (ACE) Asynchronous Event Handling Asynchronous Transfer of Control Physical Memory Access Synchronization Memory Management Scheduling www.cs.wustl.edu/~schmidt/ACE.html www.rtj.org Host Infrastructure Middleware • Host infrastructure middleware encapsulates & enhances native OS mechanisms to create reusable network programming objects • These components abstract away many tedious & error-prone aspects of low-level OS APIs Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware
Examples • OMG Real-time CORBA & DDS, Sun RMI, Microsoft DCOM, W3C SOAP realtime.omg.org/ en.wikipedia.org/wiki/Data_Distribution_Service Distribution Middleware • Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend native OS capabilities Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Distribution middleware avoids hard-coding client & server application dependencies on object location, language, OS, protocols, & hardware
Examples • W3C Web Services, CORBA Component Model & Object Services, Sun’s J2EE, Microsoft’s .NET, etc. • Common middleware services support many recurring distributed system capabilities, e.g., • Transactional behavior • Authentication & authorization, • Database connection pooling & concurrency control • Active replication • Dynamic resource management Common Middleware Services Domain-Specific Services • Common middleware services augment distribution middleware by defining higher-level domain-independent services that focus on programming “business logic” Common Middleware Services Distribution Middleware Host Infrastructure Middleware
Examples • Siemens MEDSyngo • Common software platform for distributed electronic medical systems • Used by all Siemens MED business units worldwide Modalities e.g., MRI, CT, CR, Ultrasound, etc. • Boeing Bold Stroke • Common software platform for Boeing avionics mission computing systems Domain-Specific Middleware Domain-Specific Services • Domain-specific middleware services are tailored to the requirements of particular domains, such as telecom, e-commerce, health care, process automation, or aerospace Common Middleware Services Distribution Middleware Host Infrastructure Middleware
Domain-Specific Services Common Middleware Services Distribution Middleware Host Infrastructure Middleware Operating Systems & Protocols Consequences of COTS & IT Commoditization Applications • More emphasis on integration rather than programming • Increased technology convergence & standardization • Mass market economies of scale for technology & personnel • More disruptive technologies & global competition • Lower priced—but often lower quality—hardware & software components • The decline of internally funded R&D • Potential for complexity cap in next-generation complex systems Hardware Not all trends bode well for long-term competitiveness of traditional R&D leaders Ultimately, competitiveness depends on success of long-term R&D on complex distributed real-time & embedded (DRE) systems
Load Balancing Fault Tolerance Workload & Replicas End-to-end QoS policies RT CORBA + DDS RTOS + RT Java CPU & memory Network latency & bandwidth IntServ + Diffserv Gigabit Ethernet DRE Systems: Remaining Challenges • Limit to how much application functionality can be refactored into reusable COTS middleware for DRE systems • Middleware itself has become very hard to use & provision statically & dynamically DRE Applications Middleware Services Middleware Operating System & Protocols • Component-based DRE systems are also very hard to deploy & configure Hardware & Networks
RT CORBA Apps J2ME Apps DDS Apps RT CORBA Services J2ME Services DDS Services Load Balancing Fault Tolerance Workload & Replicas RT CORBA J2ME DDS End-to-end QoS policies RT CORBA + DDS RTOS + RT Java CPU & memory Network latency & bandwidth IntServ + Diffserv Gigabit Ethernet DRE Systems: Remaining Challenges • Limit to how much application functionality can be refactored into reusable COTS middleware for DRE systems • Middleware itself has become very hard to use & provision statically & dynamically DRE Applications Middleware Services Middleware Operating System & Protocols • Component-based DRE systems are also very hard to deploy & configure • There are many middleware platform technologies to choose from Hardware & Networks Middleware alone cannot solve large-scale DRE system challenges!
RT CORBA Apps J2ME Apps DDS Apps RT CORBA Services J2ME Services DDS Services RT CORBA J2ME DDS Gigabit Ethernet DRE Systems: Remaining Challenges DRE Applications Middleware Services Middleware Operating System & Protocols Hardware & Networks It’s enough to make you scream!
RT CORBA Apps J2ME Apps DDS Apps RT CORBA Services J2ME Services DDS Services RT CORBA J2ME DDS Gigabit Ethernet Promising Solution: Model-Driven Engineering • Develop, validate, & standardize generative software technologies that: • Model • Analyze • Synthesize & • Deploy/configure • multiple layers of middleware & application components that require simultaneous control of multiple QoS properties end-to-end • Partial specialization is essential for inter-/intra-layer optimization & advanced product-line architectures <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> Middleware Operating System & Protocols Hardware & Networks Goal is to enhance developer productivity & software quality by providing higher-level languages & tools for middleware/application developers & users
Computer-Aided Software Engineering Translation Model Model Model Model Model Model Translation Translation Generated Code Model Model Code Code Code Code Code Code Platform Large Semantic Gap • State chart • Data & process flow • Petri Nets Technology Evolution Programming Languages & Platforms Level of Abstraction C/Fortran Operating Systems Assembly Machine code Hardware
Model Model Model Model Model Model Model Application Code Application Code Application Code Application Code Generated Code Generated Code Generated Code Framework Framework Framework Framework Domain Specific Domain Specific Domain Specific Domain Specific Pattern Language Pattern Language Pattern Language Pattern Language Framework Framework Framework Framework Platform Platform Platform Platform Platform Platform Platform Platform Frameworks Frameworks Frameworks Frameworks Technology Evolution Programming Languages & Platforms • Modern 3rd-generation languages & middleware platforms have raised abstraction level significantly • “Horizontal” platform reuse alleviates the need to redevelop common services • There are two problems, however: • Platform complexity has grown at a faster rate than 3rd-generation languages can alleviate it • Much application/platform code is still (unnecessarily) written & maintained manually Level of Abstraction Components Frameworks C++/Java Class Libraries C/Fortran Operating Systems Assembly Machine code Hardware
Domain-specific modeling languages • ESML • PICML • Mathematica • Excel • Metamodels Saturation!!!! Manual translation • Domain-independent modeling languages • State Charts • Interaction Diagrams • Activity Diagrams Semi-automated Technology Evolution Programming Languages & Platforms Model-Driven Engineering (MDE) Level of Abstraction Components Frameworks C++/Java Class Libraries C/Fortran Operating Systems Assembly Machine code Hardware
Domain-specific modeling languages • ESML • PICML • Mathematica • Excel • Metamodels Model Model Model Model Model Model Model Model Manual translation Generated Code Application Code Generated Code Generated Code Application Code Application Code Generated Code Application Code Framework Framework Framework Framework Domain Specific Domain Specific Domain Specific Domain Specific Pattern Language Pattern Language Pattern Language Pattern Language Framework Framework Framework Framework Platform Platform Platform Platform Platform Platform Platform Platform Frameworks Frameworks Frameworks Frameworks Technology Evolution Programming Languages & Platforms Model-Driven Engineering (MDE) Level of Abstraction • Domain-independent modeling languages • State Charts • Interaction Diagrams • Activity Diagrams Components Frameworks Semi-automated C++/Java Class Libraries C/Fortran Operating Systems Assembly Machine code Hardware
Domain-specific modeling languages • ESML • PICML • Mathematica • Excel • Metamodels Needs Automation Model Model Model Model Model Model Model Model Needs Automation Generated Code Generated Code Application Code Generated Code Application Code Application Code Application Code Generated Code Platform Platform Platform Platform Platform Platform Platform Platform Frameworks Frameworks Frameworks Frameworks Technology Evolution Programming Languages & Platforms Model-Driven Engineering (MDE) Level of Abstraction Needs Automation • Domain-independent modeling languages • State Charts • Interaction Diagrams • Activity Diagrams Components Frameworks C++/Java Class Libraries C/Fortran Operating Systems • More R&D is needed to • Automate DSMLs & model translators • Simplify usage & encourage adoption Assembly Machine code Hardware
Future Trend: Ultra-Large-Scale (ULS) Systems ULS systems are socio-technical ecosystems comprised of software-reliant systems, people, policies, cultures, & economics • ULS systems have unprecedented scale in the following dimensions: • • # of lines of software code & hardware elements • • # of connections & interdependencies • • # of computational elements • • # of purposes & user perception of purposes • • # of routine processes & “emergent behaviors” • • # of (overlapping) policy domains & enforceable mechanisms • • # of people involved in some way • Amount of data stored, accessed, & manipulated • • … etc … www.sei.cmu.edu/uls
Examples of Emerging ULS Systems ULS systems are systems-of-systems at Internet scale
Scale Changes Everything • Characteristics of ULS systems that arise because of their scale include • • Decentralization • • Inherently conflicting, unknowable, & diverse requirements • • Continuous evolution & deployment • • Heterogeneous, inconsistent, & changing elements • • Erosion of the people/system boundary • • “Normal” failures • • New paradigms for acquisition & policy • These characteristics appear in some of today’s systems, but in ULS systems they will dominate • These characteristics undermine the assumptions that underlie today’s technology approaches, rendering incremental solutions inadequate
Key R&D Challenges for ULS Systems Developers & users of ULS systems face challenges in multiple dimensions Logical View Process View Use Case View Physical View Development View Of course, developers of today’s large-scale systems also face these challenges, but they can often “brute force” solutions…
Popular technologies & tools provide inadequate support for • Expressing design intent more clearly using domain concepts • Checking pre-/post-conditions & invariants • Specifying & analyzing dependencies Key R&D Challenges for ULS Systems Logical View Determining units of abstraction for system (de)composition, reuse, & validation
Popular technologies & tools provide inadequate support for • Configuring & customizing components for application requirements & run-time environments • Automated deployment, i.e., mapping of components onto nodes in target environments Key R&D Challenges for ULS Systems Physical View Integrating/deploying diverse new & reusable application components in a networked environment to ensure end-to-end QoS requirements
Popular technologies & tools provide inadequate support for • Identifying & reducing performance & robustness risks early in ULS system lifecycles • Satisfying multiple (often conflicting) QoS demands • e.g., secure, real-time, reliable • Satisfying QoS demands in face of fluctuating/insufficient resources • e.g., mobile ad hoc networks (MANETs) Key R&D Challenges for ULS Systems Devising execution architectures, concurrency models, & communication styles that ensure multi-dimensional QoS & correctness of new/reusable components Process View
Popular technologies & tools provide inadequate support for avoiding • Cyclic dependencies, which make unit testing & reuse hard • Excessive link-time dependencies, which bloat size of executables • Excessive compile-time dependencies, where small changes trigger massive recompiles Key R&D Challenges for ULS Systems (De)composing systems into separate, reusable modules (e.g., packages, subsystems, libraries) that achieve/preserve QoS properties Development View
Popular technologies & tools provide inadequate support for • Ensuring semantic consistency & traceability between requirements & software artifacts • Visualizing software architectures, designs, & implementations from multiple views • Effective collaboration between users & distributed development teams Key R&D Challenges for ULS Systems Capturing functional & QoS requirements of systems & reconciling them with other views during evolution Use Case View
Software Engineering Institute (SEI) Overview • Federally-Funded Research & Development Center (FFRDC) • www.sei.cmu.edu • Created in 1984 • Administered by Carnegie Mellon University • Headquartered in Pittsburgh, Pennsylvania; offices in Washington DC area & Frankfurt; support worldwide • Many important contributions to software engineering & software technology 1985 1990 1995 2000 2005 2010
SEI Mission & Strategy • The SEI works to: • Identify, research, evaluate, & advise on software engineering technologies, trends, & practices • Collaborate with & leverage work found in industrial research, academia, & government laboratories • Mature promising software engineering technologies to enable standards, transition, & adoption within the DoD community • Enable government & industry organizations to make measurable improvements in their software engineering practices
SEI's Technical Strategy for Software-Reliant DoD Systems Exploratory activities to identify risk/reward potential as a sustained research initiative (~1 year initial duration) Line-Funded Exploratory New Starts (LENS) • Accelerating Assured Software Delivery & Sustainment for the Mission Sustained research initiatives (~3-4 year duration, depending on progress against measures of success reviewed annually) Application of research to practice in acquisition programs & DoD/IC domains EXPLORE CREATE APPLY AMPLIFY SUSTAIN • See blog.sei.cmu.edu for additional coverage of SEI R&D activities
Concluding Remarks • The growing size & complexity of DRE systems requires significant innovations & advances in processes, methods, platforms, & tools • Not all technologies provide precision of legacy real-time & embedded systems • Advances in Model-Driven Engineering & component/SOA-based DRE middleware are needed to address ULS systems challenges • Significant groundwork laid in DARPA & NSF programs • Much more R&D needed to assure key quality attributes of ULS systems • See blog.sei.cmu.edu for additional coverage of SEI R&D activities