Designing the Future of Embedded Systems at DARPA

Designing the Future of Embedded Systems at DARPA IXO Dr. Douglas C. Schmidt dschmidt@darpa. mil Program Manager Information Exploitation Office Authorized for Public Release: Distribution Unlimited

DARPA IXO Embedded Systems Programs Large Grain ARMS Small Grain NEST System Technology Design Technology Mo. BIES PCES Air Frame HUD Nav WTS Cross-cutting Concerns Synchronization Persistence Memory Management Fault Tolerance Event Channel Replication Service Object Request Broker GPS IFF FLIR

Technology Transition Process Initial DARPA IXO Program Structure OEP-2 Technology domain spanned OEP-1 Funding/ Directing/ Advising DARPA/Do. D Stakeholder Role DARPA Set direction, supplies funding End Users Set Do. D needs, market potential, stake in progress, augment funding Open Experimentation Platform (OEP) Define challenge problems, measure progress, ensure Do. D transition Tool Vendors Follow programs & stimulate commercial transition Standards & Certification Involve in adopting & creating standards & certification processes based on emerging architectures & best practices Open Experimental Platform-1 End-user/ Tech. Tr. target Open Experimental Platform-2 Tech. transfer to COTS tools Tech. transfer to standards End User/ Tech. Tr. target Tool Vendors Standards & Certification Bodies GROW A COMMERCIAL MARKET Technology Developers (Universities, R&D organizations)

Technology Transition Process After DARPA Exits Expanded Technology Domain Stakeholder Role Do. D Services Additional R&D as needed Defense Industry Market for created COTS Commercial Industry Incentive to generate COTS DARPA Leave-behinds Open repositories & reference solutions Do. D Programs Do. D Agencies Defense Industry Commercial Applications Non-Defense Industry Standards & Certification Bodies SELF-SUSTAINING COMMERCIAL MARKET DARPA Leave-Behinds National Experimental Platforms • Reference Solutions • Open Tool Integration Framework • Open Code Bases & Repository • Open Tool Repository Technology Developers Tool Vendors COTS tools Large vendors Small companies/ Startups Universities

ARMS Adaptive & Reflective Middleware Systems INTERNETWORKING ARCH RTP TFTP HTTP TELNET DNS UDP TCP IP Fibre Channel Ethernet ATM FDDI 20 th Century The objective of ARMS is to create the new generation of middleware technologies for distributed real-time & embedded (DRE) combat systems to enable 1. Simultaneous control of multiple Qo. S properties & 2. Composable & customizable Do. D common technology bases Dr. Douglas C. Schmidt DARPA IXO MIDDLEWARE ARCH Middleware Applications Middleware Services Middleware Solaris Win 2 K Vx. Works Linux Lynx. OS 21 st Century

ARMS Technical Focus: Real-time Control of Distributed Resources Create new generation of middleware to simultaneously control multiple Qo. S properties Distributed security Distributed fault tolerance Applications Distributed resource management Middleware • Allocation/reservations, caching, scheduling, monitoring, & load balancing OS & Protocols Hardware TBMD Application AAW Application Qo. S Requested Qo. S Measured Qo. S } Local middleware Global Middleware Control Algorithm Workload & Replicas Control Algorithm Control Vars. Control Algorithm Workload & Replicas Connections & priority bands CPU & memory Network latency & bandwidth Ship-wide Qo. S Doctrine & Readiness Display

ARMS Technical Agenda: Adaptive & Reflective Middleware Research Challenges • Assuring dynamic flexibility and Qo. S simultaneously • Devise middleware to formally specify Qo. S-constrained global resource management plans; model, reason about and refine them; & monitor/enforce these plans automatically at run-time hi lo hi System Utility lo Quality of Service Problem • Existing DRE systems are rigidly designed with fixed Qo. S parameters that limit their utility for new missions hi Solution Approach • Meta-programming techniques that • Decouple functional & Qo. S paths to allow more degrees of freedom • Specify Qo. S doctrine declaratively • Support dynamic Qo. S adaptation & optimizations lo hi System Utility lo • Secure multi-level distributed resource management Applications Interceptor Sys Cond Middleware Workload & Replicas Local Resource Managers Connections & priority bands } Sys Cond Mechanism & Property Managers Qo. S Doctrine Interceptor Middleware { Workload & Replicas Connections & priority bands CPU & memory Network latency & bandwidth Endsystem Local Resource Managers Endsystem

Applications of ARMS Technology Target Application: Total Ship Computing Environments Key System Functionality ARMS Middleware Technologies Navy Benefits • Sensor systems • Load-invariant tactical performance • Distributed real-time processing • Command & control systems • Information access • Qo. S-enabled open systems • Engagement systems • Dynamic mission flexibility • Portability • Weapons control systems • Continuous availability • Scalability • Weapons systems • Rapid upgrades • Secure fault tolerance • Low ownership cost • Shared resource management • Reduced manning • Self-adaptive Program Impact • Important Do. D systems will be more assurable, adaptable, & affordable • e. g. , network-centric warfare, total ship computing environments, theater ballistic missile defense • Researchers will have higher-level techniques & tools to enhance future R&D

Mo. BIES Model-Based Integration of Embedded Systems The objective of Mo. BIES is to develop technology to flexibly integrate the physics of the underlying domain with the embedded software design tools in order to custom-tailor the software process to the application Model Builders Data/Meta. P-IF Model Rep. Data/Meta Open Tool Integration Framework Timing Generator Hybrid Analysis Generator Safety Simulation Data/Meta. P-IF Data/Meta. Data Fault Analysis Data/Meta. P-IF Data/Meta. Data Analysis Data/Meta. Data Exec. Frame. Exec. work Framework Customization Components Dr. John S. Bay DARPA IXO Analysis Simul. Synth. Analysis Transl. Meta. Prog. Model Builder Meta. P-IF Gen. Model Rep. Meta-IF Gen Exec. Framework

Mo. BIES Technical Agenda DESIGN TOOLS • Models of broad physical processes • Models of time and concurrency • Mathematical models for … (HW) (SW) – analysis tools (HW&SW) – scheduling – code generation (generator-generators) • Framework & toolsuite integration DESIGN TOOLS for (Application INdependent) (Application Dependent) • • • Reduced design space Formal specification languages Correct-by-construction generators Tailored models of computation Reduced V&V complexity Composable tool market MODEL-BASED INTEGRATION DESIGN PROCESS Mo. BIES Embedded Systems for

Mo. BIES Technical Focus: Model-Based Integration of Embedded Software Complex but Inert Machine Complex Operational Embedded System Embedded Software if (inactive. Interval != -1) { int this. Interval = ( int)(System. current. Time. Millis () - last. Accessed ) / 1000; if ( this. Interval > inactive. Interval ) { invalidate(); Server. Session. Manager ssm = Server. Session. Manager. get. Manager (); ssm. remove. Session (this); } } } private long last. Accessed. Time = creation. Time ; /** * Return the last time the client sent a request associated with this * session, as the number of milliseconds since midnight, January 1, 1970 * GMT. Actions that your application takes, such as getting or setting * a value associated with the session, do not affect the access time. */ public long get. Last. Accessed. Time () { return (this. last. Accessed. Time ); } this. last. Accessed. Time = time; /** * Update the accessed time information for this session. This method * should be called by the context when a request comes in for a particular * session, even if the application does not reference it. */ public void access() { + this. last. Accessed. Time this. New =false; Structural analysis Dynamic equations CAD modeling and simulation Part interaction analysis Sensor and actuator circuits DEVICE PHYSICS = 0 L; last. Accessed. Time = ((Long) stream. read. Object ()). long. Value (); max. Inactive. Interval = ((Integer) stream. read. Object ()). int. Value (); is. New = ((Boolean) stream. read. Object ()). boolean. Value (); Mathematical Models • • • = this. Accessed. Time ; = System. current. Time. Millis (); } last. Accessed. Time Mo. BIES Tools • • • = Requirements PERFORMANCE • Real-time control Intelligent programming tools REQUIREMENTS • Network connectivity Smart process schedulers • Fault tolerant/fail safe Communications configuration • Harsh environment On-line resource allocation • Size/weight/power/thermal User interfaces constraints Automatic code generation Mo. BIES finds the underlying Application-Specific Mathematical Principles of the Embedded Software, enabling us to … • • Generate complex software automatically; not through laborious manual coding Guarantee that generated code is correct; do not rely on after-the-fact testing Provide application engineers programming interfaces using their own terminology Tailor and specialize programming tools to the systems they are designing Over 99% of all microprocessors manufactured today are destined for embedded applications; we need software tools tailored to those special needs.

Potential Applications of Mo. BIES Technology JOINT DARPA/ SERVICE PROGRAMS MAJOR WEAPONS PROGRAMS COMMERCIAL USERS SOFTWARE TOOL VENDORS STANDARDS BODIES

NEST Networked Embedded Software Technology The objective of NEST is to develop robust coordination & synthesis services to support networked embedded systems of 100 to 1, 000 nodes Dr. Vijay Raghavan DARPA IXO

NEST Technical Focus: Robust Coordination Services Distributed Control of Finegrain Network of MEMS devices Time Service Local Clock CONTROL+DISTRIBUTED Consensus Service resolution Networked • sufficient Processes • fault resilience v 1 v Reference Clock v 2 v A common v is selected: • uniform agreement • uniform validity (v {vi}) • the protocol terminates Mathematical Models Distributed Control Algorithms Stability, dynamics Network models Device models Precision Local clocks are synchronized: • limit the effects of clock drift + • • Missions for Coordinated Fleets of UAV-s Coordination Services vj = v vk v = NEST Tools • • Requirements COORDINATION • Physical: power, dynamics Micro-protocols for coordination REQUIREMENTS • Communication quality Time-bounded synthesis • Coordination Service methods Requirements Service package synthesis tools • Mission modality Reference solutions ALGORITHMS NEST provides the computational foundation for building large-scale distributed control applications by implementing services for coordination such that … • Control algorithms may assume guarantees for time, consensus, and other requirements • The service packages are customized to the needs of applications Networked embedded systems represent a new wave in technology. NEST provides the groundwork for making new applications feasible.

NEST Technical Agenda Applications: Acoustic damping, Distributed Network of Sensor Motes Tasks: Coordination, Synthesis, Composition Berkeley OEP Determinism, realtime constraints Extreme Scaling Resource Constraints, nondeterminism, dynamism Extreme Scaling Boeing OEP

Applications of NEST Technology Distributed Network of sensor motes for environmental monitoring, tracking, surveillance (1, 000 nodes): An experimental platform in the NEST program Distributed Active Control: Vibration Damping on Delta-4 Rocket Payload Fairing (1, 000 nodes) An experimental platform in the NEST program Actuators for Vortex Control (10, 000 nodes) Noiseless sonar on submarines to provide camouflage (3, 000 nodes) 100 – 1, 000 node fusion of physical and information systems Gossamer Space Reflector (1, 000 nodes) High resolution reconnaissance, GMTI Smart reconfigurable engines (100 nodes)

PCES Program Composition for Embedded Systems The objective of PCES is to create programming language & compiler technology that enables developers to safely & productively weave cross-cutting aspects with real-time (RT) embedded program functionality AP Air Frame Nav HUD Event Channel WTS Replication Service Object Request Broker GPS IFF FLIR Dr. Douglas C. Schmidt DARPA IXO

PCES Technical Focus: Real-time Plug & Play Avionics Systems PCES provides language & compiler technology to safely & productively program & evolve cross-cutting aspects to support real-time middleware & “plug & play” avionics applications Key System Functionality • Weapons targeting systems (WTS) • Airframe & navigation (Nav) • Sensor control (GPS, IFF, FLIR) • Heads-up display (HUD) • Auto-pilot (AP) First Generation: Free form Spaghetti Nav AP GPS Air Frame WTS FLIR IFF Data Links Nav Sensors Vehicle Mgmt Mission Computer Radar Weapon Management Weapons Second Generation: Components Air Frame AP Event Channel Nav WTS Replication Service Key Cross-cutting Systemic Aspects • Synchronization • Memory management & persistence • Fault tolerance & error handling • Real-time deadlines • Bandwidth & CPU management Third Generation: Aspects & Components Air Frame AP Event Channel Nav WTS Replication Service Object Request Broker GPS Cyclic Exec Small changes can break everything IFF FLIR Object Request Broker Cross-cutting changes can break everything GPS IFF FLIR Cross-cutting Concerns Synchronization Persistence Memory Management Fault Tolerance Many changes can be done easily

PCES Technical Agenda: Systemic Aspects for Real-time Avionics Functional code HUD AP Nav WTS Air Frame e. g. , Core Mission Computing Algorithms Programmed PROGRAM ANALYZER Real-time Middleware Event Channel Replication Service • • Synchronization Fault Tolerance Persistence Error handling Program/Aspect Representations Staging Controller • Compile time • Link time • Download time • Run time Logging aspect Aspect Code WEAVER Reusable ASPECT ANALYZER Issues • Binding time • Order of specialization • Scope of properties • Conservative analysis Mission Computer Code Object Request Broker BBN, & LMCO TCT OEP C 2 assets & strike aircraft share imagery data in real-time • • Synchronized Fault tolerant Persistent Robust void HUD_update (int id, Coords coords) { HUDID a. Hud=null; try { a. Hud= hud. Repo. get. Hud(id, coords); } catch (Error e) { log. write (e); } try { the. Display. print(id, a. Hud); } catch (Error e) { log. write (e); } return true; } Auto-tangled code Boeing Bold Stroke OEP PCES Architecture Applications of PCES Language & Compiler Technology Avionics Applications aspect Public. Error. Logging { static Log log = new Log(); pointcut public. Entries (): receptions(public *com. boeing. . *. *(. . )) after() throwing (Error e): public. Entries() { log. write(e); } } void HUD_update (int id, Coords coords) { HUDID a. Hud=null; a. Hud= hud. Repo. get. Hud(id, coords); the. Display. print(id, a. Hud); return true; }

Applications of PCES Technology Unmanned Systems Radar Control Systems Hot Rolling Mill Tactical Aircraft Quality Control Shipboard Computing stributed Interactive Simulation Stock Trading Military Communications

Characteristics of Successful DARPA Embedded System Technology Transitions • Program structure conveys & enforces endstate vision(s) • e. g. , OEPs help to guide R&D efforts & build end-user alliances to Services & industry integrators/vendors • Explicit focus on constraints of transition environment(s) • Performance, footprint, languages, tools, & commercial trends THROUGHPUT LATENCY • Provide decomposible & easily customizable component interfaces & implementations • This generation’s successful transitions are often last generation’s successful R&D projects Level of Technology Abstraction • Leverage R&D maturation cycles to “cross the chasm” of transition successfully hi lo DRTS Java RT Linux Dynamic RT CORBA Researchers Practitioners Java Linux RT CORBA C++ UNIX CORBA C/Ada Cyclic execs Proprietary ’ 90 -’ 95 C++ UNIX CORBA ’ 96 -’ 01 Java Linux RT CORBA ’ 02 -’ 06