Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems

1. Cadena:An Integrated Environment for Developing High-Assurance Component-based Systems SAnToS Laboratory, Kansas State University, USA http://www.cis.ksu.edu/cadena Principal Investigators Postdocs and Students Radu Iosif Hongjun Zheng Corina Pasareanu Georg Jung Robby Venkatesh Ranganath Oksana Tkachuk William Deng Matt Dwyer John Hatcliff Gurdip Singh Support US National Science Foundation (NSF) US National Aeronautics and Space Agency (NASA) US Department of Defense Advanced Research Projects Agency (DARPA) US Army Research Office (ARO) Rockwell-Collins ATC Honeywell Technology Center and NASA Langley Sun Microsystems Intel

2. Distributed Components Network

3. Distributed Components Interface Definition Language (IDL) specifications for remote methods Automatically generated proxies Java C++ C Middleware (e.g. CORBA) C Java C++

4. Distributed Components Event Service Transaction Service Component Interface Definition Language (CCM IDL) Naming Service Synchronization Service substantial portion of code auto-generated Java C++ C Middleware (e.g. CORBA) C Java C++

5. Checking CCM Systems Transaction Service Event Service Naming Service Synchronization Service Modern Software Systems Our Themes • Light-weight behavioral specifications • Leverage abstractions that programmers already write • Component IDL • Scale static analysis techniques to handle remote connections • Use emerging model-checking technology dedicated to OO structures and RT scheduling algorithms Java C++ C Middleware (e.g. CORBA) C Java C++ • These systems are huge! • What are appropriate abstractions/specifications and how can we get programmers to write them?

6. Analysis & Verification of Fighter Aircraft Mission Control Systems • Mission-control software for Boeing military aircraft, e.g., F-18 E/F, Harrier, UCAV • Boeing’s Bold Stroke Avionics Middleware • …built on top of ACE/TAO RT CORBA • Our focus: developing a rigorous design process with formal design artifacts that can be automatically checked for common design flaws

7. Boeing Bold Stroke Platform Focus Domain Nav Sensors Weapon Management Data Links Weapons Periodic & Aperiodic Constrained Tactical Links Many Computers Mission Computer Multiple Safety Criticalities Radar Vehicle Mgmt COTS Information Security Multiple Buses O(106) Lines of Code Hard & Soft Real-Time

8. Control-Push Data-Pull dataAvailable getData() dataAvailable getData() A publishes a dataAvailable event Bicall the getData() method of A to fetch the data Typical situation Component A computes some data that is to be read by one or more components Bi B1 A Bk Run-time Actions

9. Control-Push Data-Pull Structure 4 4 1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device. Input 1 2. Logical GPS publishes DATA_AVAILABLE event 3. Airframe component fetches GPS data by calling GPS GetData method 2 4. Airframe updates its position data and publishes DATA_AVAILABLE event 3 6 5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method 5 6. NavDisplay updates the physical display Output

10. Larger Configuration …moving up to 1000+ components

11. Development Process Component Integration Platform-specific Components Common Components Connect components, assign priorities, locking schemes, distribute Real Board Testing Analysis & Functional Testing Test real-time aspects, frame-overruns, etc. Debuggers, call-graph analyzers, scheduling tools Component Development 100+ developers

12. Research Context • Provided with an Open Experimental Platform (OEP) from Boeing • a sanitized version of the real system • 100,000+ lines of C++ code (including RT CORBA middleware) • Provided with 150+ page document that outline development process and describe challenge problems • Must provide tool-based solutions that can be applied by Boeing research team to realistic systems • Must propose solutions that fit within current development process, code base, etc. • Must propose metrics for tool performance and ease of use • evaluation by Boeing research team • Must make significant progress in one year with regular evaluation milestones

13. Next… Short-comings in Bold Stroke development that we will attempt to address One could imagine doing a number of things. We first focused on items in Boeing’s “wish list”.

14. Lack of Modeling C++ component library development bypasses modeling Informal natural language requirements <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> XML component connection information • Process moves directly from informal textual requirements documents to C++ coding (!) • No use of component-level (CCM) IDL for code generation • Still resistance by “legacy developers” to higher-level descriptions (moving away from machine code has been difficult for some)

15. Unleveraged Artifacts • Current design/model artifacts are used as informal documentation • not connected to analysis/visualization tools • not connected to “glue code” (deployment code) generation

16. Lack of Model Analysis 4. All components from a particular rate group 5. Cycle checks …15-20 others related to dependencies Boeing OEP Challenge Problems 1. Forward & backward data and event dependencies 2. Dependency intersections 3. Components with high data coupling …also mode-aware dependences

17. Lack of Model Analysis Boeing OEP Challenge Problems If component 1 is in mode A when component 2 produces event E, then component 3 will consume event F (Section 4.1.5.3.6) A temporal property well-suited for model-checking!

18. No Unifying Mechanism ? C++ Component Code Design Artifacts <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> High-level Specification Language Bold Stroke XML Configurator Info Integrated Development Environment Analysis and QoS Aspect Synthesis

19. Cadena Cadena CCM Interface Definition Language Java/C++ Component Code RT Aspect Specs UML Design Artifacts State Transitions System Configuration <CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME> </CONFIGURATION_PASS> High-level Specification Language Eclipse Plug-In Bold Stroke XML Configurator Info Integrated Development Environment Analysis and QoS Aspect Synthesis

20. Next… Cadena functionality and capabilities…

21. Example System

22. Example System Basic components seen earlier

23. Example System Navigation Steering Subsystem

24. Example System Tactical Steering Subsystem

25. Example System on/off on/off Display Control

26. Outline 4. Modal Behavior 1. Component Interface 2. Component Connections 3. Dependence Information

27. CCM Component Interfaces • CCM Component Interfaces are based on a notion of ports • Event ports – asynchronous event delivery • consumesport – input (event sink) • publishes port – output (event source) • Interface ports – synchronous method calls • provides port – provide interface to clients (facet) • uses port – use interface of other component (receptacle)

28. Component Ports input event port CORBA 3 CCM IDL eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { readonly attribute any data; } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut }

29. Component Ports CORBA 3 CCM IDL eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { readonly attribute any data; } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut } output event port

30. Component Ports CORBA 3 CCM IDL eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { any get_data(); } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut } provide interface to clients (facet)

31. Outline 2. Component Connections

32. Component Connections • Three ways in Cadena • A textual language for allocating component instances and describing port connections • A graphical representation of the same • analogous to UML collaboration diagram • useful for visualizing dependency information • A form-based (spreadsheet-like) view • useful for component integrator • from pull-down menus • pick ports to connect to • pick QoS attributes (rates, locations, etc.)

33. Cadena Component Assembly abstract distribution nodes system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …

34. Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … rate group declaration

35. Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … create instance of LazyActive component called AirFrame

36. Cadena Component Assembly connect event INPUT port of current component to event OUTPUT port of GPS component system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …

37. Cadena Component Assembly connect data INPUT port of current component to data OUTPUT port of GPS component system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } …

38. Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … create instance of DeviceComponent called GPS

39. Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … connect event INPUT port of current component to event OUTPUT port of EventChannel

40. Cadena Component Assembly

41. Cadena Visualization

42. Code Generation Overview component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } “Glue Code” Generation Glue Code Execution gives allocation and deployment of component instances and connections(complete system) Component Code Generation … BM.Device BM.LazyActive BM.Modal

43. Outline 3. Dependence Information

44. Dependency Specifications • Inter-component dependences are given by connection information (already seen) • We now give notation for specifying intra-component dependencies • An example of Meyer’s “something intelligent/useful” that a developer or manager might want to know • In this case, component integrator leverages this info in a variety of ways to specify aspects such as rates/priorities, distribution, scheduling, etc. • Used to visualize system behavior in different modes

45. Light-weight Dependency Specs outDataAvailableport action call on set_data() triggers dependencydefault == none; dependencies { dataWriteOut.set_data() -> outDataAvailable; } behavior { ... }

46. Light-weight Dependency Specs triggers no other actions dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } } behavior { ... }

47. Light-weight Dependency Specs in enabled mode, shows actions triggered by receipt of event on inDataAvailable port dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } } behavior { ... }

48. Light-weight Dependency Specs in disabled mode, inDataAvailable triggers no other port actions dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } } behavior { ... }

49. Aspect Synthesis 5Hz 5Hz 20Hz 20Hz 20Hz 20Hz 1Hz 20Hz 20Hz Dependency-driven rate assignment to event handlers

50. Cadena User Interface