Cadena: An Integrated Environment for Developing HighAssurance Componentbased Systems

1
CadenaAn 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
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
Conclusions

• Software is moving rapidly towards distributed,
  component-based systems
• Since concurrent/distributed systems are
  difficult to reason about, we would like to apply
  model-checking, static-analyses, and other formal
  methods
• To make this feasible, one needs multiple layers
  of abstraction (modern systems are huge!)
• Interface Definition Languages (e.g., CORBA IDL)
  provide an excellent hook for attaching
  light-weight formal specifications
• Model-checking modern software (heavily OO)
  requires using a tool like dSpin

3
Analysis Verification of Fighter Aircraft
Mission Control Systems

• Mission-control software for Boeing military
  aircraft, e.g., F-18 E/F, Harrier, UCAV
• Boeings Bold Stroke Avionics Middleware
• CORBA event-based systems
• Focus is developing a rigorous design process
  with formal design artifacts that can be
  automatically checked for common design flaws

4
Boeing Bold Stroke Platform
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
5
Software Infrastructure

• Programmed using a component-based Real-Time
  CORBA framework
• CORBA is middleware
• rich infrastructure for building heterogeneous
  object-oriented distributed systems
• Components communicate by
• publishing/subscribing to events
• making method calls on component interfaces
• Loose coupling addresses a number of issues
• easier to reuse components, distribution of
  resources on aircraft, easy to incorporate
  real-time aspects, easier to have disjoint groups
  of developers

6
Control-Push Data-Pull
Typical situation
Component A computes some data that is to be read
by one or more components Bi
B1
A
Bk
7
Control-Push Data-Pull Structure
1. Logical GPS component receives a periodic
event indicating that it should read the physical
GPS device.
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
8
Larger Configuration
moving up to 1000 components
9
System Requirements
Very idealized(!), but should give you the flavor
Input Requirements

• The system shall request new inputs from the GPS
  subsystem at a 40 Hz rate.
• The system shall poll for a pilot steering mode
  input at a 1 Hz rate.
• The system shall receive data from the navigator
  controls at a 5 Hz rate.

10
System Design Aspects
Declare rates/priorities for intermediate event
handlers
Off
11
Development Process
Component Development
12
Current Challenges

• Systems with 1000 components
• Development team of 100 developers
• Process moves directly from informal textual
  requirements documents to C coding (!)
• UML artifacts (e.g., collaboration diagrams) are
  usually produced only as documentation
• not automatically analyzed
• not leveraged in any way to e.g., generate
  configuration information
• usually show partial descriptions and are not
  maintained
• Still resistance by legacy developers to
  higher-level descriptions
• moving away from machine code has been difficult
  for some developers

13
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 realistic systems
• Must propose solutions that fit within current
  development process
• 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

14
Next
Short-comings in Bold Stroke development that we
will attempt to address
15
Lack of Modeling
C component library
development
Informal natural language requirements
ltCONFIGURATION_PASSgt ltHOMEgt ltgt
ltCOMPONENTgt ltIDgt ltgtlt/IDgt
ltEVENT_SUPPLIERgt ltevents this component
suppliesgt lt/EVENT_SUPPLIERgt
lt/COMPONENTgt lt/HOMEgt lt/CONFIGURATION_PASSgt
XML configurator information

• Current development includes little high-level
  modeling
• Design errors appear late in development cycle
  and correction is more costly
• what are the ramifications of switching from
  lazy-active to eager-active components?
• what are the ramifications of distributing
  components to different boards?

16
Unleveraged Artifacts

• Current design/model artifacts are used as
  informal documentation
• not connected to analysis/visualization tools
• not connected to configuration generation
• not connected to code generation

17
Lack of Model Analysis
Boeing OEP Challenge Problems
1. Forward backward data and event dependencies
2. Dependency intersections
3. Components with high data coupling
also mode-aware dependences
18
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!
19
No Unifying Mechanism
?
C Component Code
UML Design Artifacts
ltCONFIGURATION_PASSgt ltHOMEgt ltgt
ltCOMPONENTgt ltIDgt ltgtlt/IDgt
ltEVENT_SUPPLIERgt ltevents this component
suppliesgt lt/EVENT_SUPPLIERgt
lt/COMPONENTgt lt/HOMEgt lt/CONFIGURATION_PASSgt
High-level Specification Language
Bold Stroke XML Configurator Info
Integrated Development Environment
Analysis and QoS Aspect Synthesis
20
Cadena
Cadena
CCM Interface Definition Language
Java/C Component Code
TAO Extensions
UML Design Artifacts
State Transitions
System Configuration
ltCONFIGURATION_PASSgt ltHOMEgt ltgt
ltCOMPONENTgt ltIDgt ltgtlt/IDgt
ltEVENT_SUPPLIERgt ltevents this component
suppliesgt lt/EVENT_SUPPLIERgt
lt/COMPONENTgt lt/HOMEgt lt/CONFIGURATION_PASSgt
High-level Specification Language
Eclipse Plug-In
Bold Stroke XML Configurator Info
Integrated Development Environment
Analysis and QoS Aspect Synthesis
21
Example System
22
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
23
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
event source
24
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
data source (facet)
25
Component Code Generation
Currently in Bold Stroke
8-12 classes drawn by hand in Rational Rose, then
code templates generated from this (component
structure must be re-specified each time).

Push()
GetData()
tacticalSteering
BM__ModalComponent
Push()
GetData()
26
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
27
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
28
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
29
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
30
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
31
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
32
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
33
Cadena Component Assembly
34
Cadena Visualization
35
Glue Code Generation
Current Boeing Glue Code Generation
ltCONFIGURATION_PASSgt ltHOMEgt ltgt
ltCOMPONENTgt ltIDgt ltgtlt/IDgt
ltEVENT_SUPPLIERgt ltevents this component
suppliesgt lt/EVENT_SUPPLIERgt
lt/COMPONENTgt lt/HOMEgt lt/CONFIGURATION_PASSgt
Bold Stroke XML Configurator Info
Glue Code
36
Code Generation Summary
Component Code Generation

BM.Device
BM.LazyActive
BM.Modal
37
Assessment

• Weve done a lot of work already and none of it
  has to do with model-checking.
• Tool building reading CCM spec (1000 pages!)
• But
• Boeing developers now have high-level artifacts
  that definitely want to use (a substantial
  benefit)
• We can now try to sneak in formal methods
  attached to these high-level artifacts
• add behavioral annotations to high-level
  artifacts
• modify code generation process to generate
  cookie-crumbs in the code that can be
  recognized by formal-methods tools to, e.g., help
  check refinement.

38
Ultimate Modeling View
CCM IDL Model Layer
Check mode behaviors, temporal properties, timing
constraints
Generate code, fill-in skeletons, check for
refinement
39
Component Behavior
input ports
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
enabled,disabled Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
40
Component Behavior
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
(enabled,disabled) Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
output ports
41
Component Behavior
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
(enabled,disabled) Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
mode declaration using CORBA IDL
42
Component Behavior
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
(enabled,disabled) Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
behavior for events on dataInReady port
43
Component Behavior
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
(enabled,disabled) Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
behavior mode cases
44
Component Behavior
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
(enabled,disabled) Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
data flow specification
45
Component Behavior
component BMModal uses ReadData dataIn
consumes DataAvailable inDataAvailable
publishes DataAvailable outDataAvailable
provides ReadData dataOut provides
ChangeMode modeChange enum Modes
(enabled,disabled) Modes m behavior
handles dataInReady (DataAvailable e)
case m of enabled
dataOutdata lt- dataIn.getData()
push dataOutReady
disabled
publish event
46
Assessment

• CCM IDL, connection information, and behavioral
  specification are enough to
• generate precise mode-aware dependence
  information
• generate models suitable for model-checking
  model-behavior
• Seems natural to some one in the model-checking
  community
• Boeing team thought writing behavior specs would
  be too much effort(!)

47
Light-weight Dependency Specs
dependencydefault all dependencies
modeChange() -gt case modeChange.modeVar of
enabled inDataAvailable -gt
dataIn.get_data(),
outDataAvailable disabled inDataAvailable
-gt behavior ...
48
Next
Now, on to modeling
49
CORBA Overview
Distributed, heterogeneous systems
C
Java
C
C
50
Event Channel
51
System Model
52
Event Channel
internal structure of event channel
53
DSpin Modeling of Components
any NavSteering_internalData mode
NavSteering_componentState ftype
Ref_NavSteering_dataIn1_getData,
Ref_NavSteering_dataIn2_getData ftype
Ref_NavSteering_update function
Fun_NavSteering_source1 (mtype t)
printf("NavSteering source1 handler
invoked.\n") if NavSteering_componentState
enabled -gt NavSteering_internalData
Ref_NavSteering_dataIn1_getData ()
printf("NavSteering publishing update.\n")
Ref_NavSteering_update (NavSteering_DataAvailable)
else fi
54
DSpin Modeling of Connections
instance AirFrame of BMLazyActive on l2
connect dataAvailable to
GPS.dataCurrent atRate 20 connect dataIn
to GPS.dataOut
Modeled very directly in DSpin
Ref_GPS_dataCurrent Proxy_GPS_dataCurrent
GPS_dataCurrent_NumberSubscribers 1
GPS_dataCurrent_SubscriberList new
functionField1 GPS_dataCurrent_SubscriberList
0.Entry Fun_AirFrame_dataAvailable
55
Functional Properties
Property I System never reaches a state where
TacticalSteering and NavSteering are both
disabled
Property II If navSteering is enabled when 20Hz
timeout occurs, then airFrame should fetch
navSteering data before end of frame
56
Temporal Property Specs
57
Assessment

• Custom-built (reusable model of event channel)
• This is a general approach that we are taking to
  modeling middle-ware
• Component models are automatically generated for
  each application
• System generated tons of infeasible interleavings
  (priorities/scheduling not taken into account)
• took all night to check for deadlock
• 20million states
• Enhanced model to include a notion of priority
• transitions have explicit guards to check for
  current priority setting
• down to 1 million states and finished in a few
  minutes

58
Assessment

• DSpin models functions and pointers with very
  little overhead compared to Spin
• we had an inlined version and the performance was
  worse
• in general, DSpins heap representation incurs
  little overhead
• note garbage collection not required in this
  application

59
Assessment

• Encoding explicit scheduling dramatically reduced
  the number of states
• BIR model-checker will allow different scheduling
  mechanisms to be encoded
• Encoding of time-aspects is primitive, but allows
  checking of interesting functional properties
• We are exploring how real-time capabilities can
  incorporated into BIR checker

60
Assessment

• Why might this technique scale for this
  application?
• Even though the number of components will grow
  dramatically, there are few threads in thread
  pool (one per rate group 4 max)
• We are now experimenting with larger scenarios

61
Conclusions (again!)

• We have spent extra effort on non-model-checking
  aspects to develop a framework where we believe
  that a variety of formal methods can be applied
  effectively
• model-checking, static-analysis, refinement
  between specs code, SAT-solving to check
  first-order logic predicates constraining
  component connections
• Cadena allows (eventually) end-to-end development
  of high-assurance CCM distributed systems
• We are leveraging a high-level specification
  format (CCM IDL)
• light-weight formal specs can be attached
• CCM IDL compilation process can be tweaked to
  insert markers to aid in checking conformance
  of code to specs
• Modern software architectures need facilities for
  functions, pointers, GC, etc. and these can be
  incorporated directly into conventional
  explicit-state model-checking engines

62
Cadena Capabilities

• High-level specification of system control
• given basic data dependencies, how is control
  structured to move data from producers to
  consumers
• Multiple ways to leverage modeling information
• visualization, dependency analysis,
  model-checking, component skeleton generation,
  configuration code generation
• Incremental capabilities within an IDE
• ability to leverage and reason about incomplete
  specs
• tools designed to support incremental, iterative
  construction
• System modes and modal behavior
• move to more high-level specs instead of having
  mode implementation distributed to individual
  components

http//www.cis.ksu.edu/santos/cadena