Transcript PowerPoint Show

Architecture-based
Software Development
on the Crusader
Program
October, 2001
Software Architecture Team
Presented by:
Scott Edgerton
United Defense L.P.
SFSC-Apr01
1
Agenda






SigAda - 2001
Crusader System overview
Software Architecture Objectives
Software Architecture Methodology
Experience of using Architecture based
development
Software Architecture Documentation
Concluding remarks and Questions
2
Crusader - A System for the 21st Century
XM2001
Propellant
Magazine
Resupply Port
Lethal Firepower
LV-100
Engine
SPH
XM29
Cannon
Crew Cockpit Enable
Information
Dominated Warfare
Projectile
Magazine
Crew
Compartments
Unmatched
Survivability
Resupply
Port
Propellant
Magazines
RSV-T
LV-100
Engine
Resupply
Port
XM2002
Resupply
Boom
Propellant
Magazine
Fully Automated
Ammo & Fuel
Resupply
M1075/XM2003
RSV-W
PLS Truck
Projectile
Magazine
Resupply
Boom
Projectile
Magazine
SigAda - 2001
Crew
Compartment
Highly Mobile
Platforms
3
Digital Battlefield Subsystems
MAN/MACHINE
INTERFACE
POS/NAV
EMBEDDED
OPERATIONAL
SOFTWARE
Appliqué
AFATDS
PLGR GPS
DISPLAYS
FRIEND OR
FOE ID
Diagnostic and Prognostic
SIP/INC/JTRS
SigAda - 2001
•Logging Diagnostic Faults
•Evaluation of Diagnostic and
Prognostic Faults
ELECTRONIC
MODULES
ITEM
•AutoLog Book
BCIS
Integrated Logistic Support
•Maintenance Support
•Replacement Parts
4
Crusader “Cockpit” Software
Flat panel displays
drive-by-wire
full situational awareness
Three crew members
SigAda - 2001
5
Crusader “Cockpit” Software
Terrain Situation Analyst (TSA)
Tactical Data Analyst (TDA)
Diagnostic and Prognostic (DAP)
• Digital Map Data
• Up to 32 tactical overlays/features editor
• Decision aids
• Manage tactical information
• Guidance
• Geometrics
• Intelligence
•
•
•
•
Logging diagnostic fault data
Evaluation of fault data
safety hazard detection / reporting
mission capability assessment / reporting
X
Navigation (NAV)
• Tightly coupled with Terrain
Situation Analyst
• Route planning weights
• Threat assessment
• Terrain evaluation
• Route Validation and
Monitoring
SigAda - 2001
Indirect Fire Control (IFC)
•
•
•
•
•
Ballistic Calculation
Weapon and supply status
Geometry's
Fire mission validation
Guidance
Communication Reporting and
Processing (CRP)
•
•
•
•
•
Data conversion
Message logging
Message status
Message prioritization
Message distribution
6
Systems of Systems Software
All Activity
Focuses on
the
Intersection
of Our
Software
Systems
AFATDS
Crusader
Advanced Field Artillery
Tactical Data System
Advanced Field Artillery System
FBCB2
Force Battle Command
Below Brigade
SigAda - 2001
GCSS-A
Global Combat Support
Systems - Army
7
System Challenges







SigAda - 2001
Complex Requirements
Diverse teams at multiple locations
Infusion of multiple technologies
Interoperability with other systems
Resilience to change
Support for meeting hard real-time requirements
Fault Tolerance
8
SW Architecture Objectives



Object-oriented design
Distributed system
Compliance with the Joint Technical Architecture
(Army)



SigAda - 2001
Defines standards profile
Domain and Product-line reuse
Standardization of interface protocols
9
Object-Oriented Approach

Advantages of an object-oriented approach are:








SigAda - 2001
Improved problem domain abstraction
Improved scalability
Better support for reliability and safety concerns
Improved facilities for reuse
Excellent modeling support (UML)
Improved stability in the presence of changes
Improved support for concurrency
Leverage the benefits of Ada95’s OO features
10
Why Emphasize Architecture?
United Defense, LP
Define Product Structure
General Dynamics
Land Systems
• Constituent “parts”
• How parts work together
• Facilitate subcontracting
Distributed Applications
• Distribution, scalability
• Quality of service
• Integration and interoperation
United
Defense,
GSD
Raytheon
Systems
Honeywell
Raytheon
Systems.
United Defense,
Orlando Opns
Commonality
Distributed Teams
• Between vehicle platforms (SPH, RSV, RSM)
• Define reuse opportunities
• “Meta-process”
• Collaborations between companies
• Multiple teams in parallel
• Geographically dispersed
SigAda - 2001
11
Definition of “Software Architecture”

Software architecture is the pattern of connections among the
basic components of the system


Pattern embodies the relations and constraints among the constituent
pieces of the system
Crusader’s method of documenting an architecture uses:


Static and dynamic models
Design patterns
Design Pattern
Interaction
Components
SigAda - 2001
12
Elements of Software Architecture
(1) What the design concepts are
and what they mean
Conceptual Framework
(4) Services
provided
Structure
Interfaces
Dynamic Behavior
(2) Components and
communication
mechanisms
(3) How the components
interact and change state
SigAda - 2001
13
Modeling Approach

Used the Unified Modeling Language (UML) to
capture our software design






SigAda - 2001
Use Case View
Logical View
Component View
Concurrency View
Deployment View
A single “integrated” model is used by all
geographically distributed development teams
14
Use Case View

Ten use cases identified at the system level

SigAda - 2001
Hundreds of <<uses>> and <<extends>> have been derived
from these use cases.
«Use Case»
Init & Config
«Use Case»
Indirect Fire
«Use Case»
Move
«Use Case»
Resupply
«Use Case»
Defense
«Use Case»
Training
«Use Case»
Maintain
«Use Case»
Decision Aids
«Use Case»
Communicate
«Use Case»
Operate Equipment
15
Logical View
Crew Interface
Offboard Test & Training
Embedded Support
Mobility
«Global»
Interface Services
Survivability
Resupply
«Global»
Peripheral Services
«Global»
Utilities
SigAda - 2001
Command & Control
Armament
«Global»
RTCOE Services
Battlefield
«Global»
Common Types & Abstracts
Bindings & Drivers
16
Component View
«layer»
Processes

Describes organization of
components

«layer»
External Visibility

«layer»
Command & Control

«layer»
Virtual Vehicle
«layer»
Distributed Services
Layers, subsystems,
modules
Used subsystems for
reuse and configuration
management
Shows the compile-time
dependencies and
packaging structure of the
deployed system
«layer»
OS Abstraction
SigAda - 2001
17
Concurrency View
SPH Combat
State
SPH Live Fire
Exercise State
SPH Active Dry
Fire State
SPH Passive
Dry Fire State
SPH Administrative
Operations State
select
substate
SPHMaintenance
State
SPHInd/Crew
Training State
Used state diagrams
and sequence
diagrams
extensively
Vehicle behavior is
based on states and
modes
SPH CPX/DIS
State
select
administrative
SigAda - 2001
SPH Solo Dry
Fire State
18
Deployment View
GPU11a
Admin_Manager
Admin_Agent
User_Interface
Display_Support
Proxy_X
Combat_ID
Navigation
Power_Control
External_Comm
GPU11b
Gateway
Segmentation
Subnetwork
SAIU11
Admin_Agent
Vehicle_Env
Mobility
Fuze_Setter
SigAda - 2001
GPU12a
Admin_Agent
User_Interface
Display_Support
Proxy_X
Mission_Mgmt
Indirect_Fire
SAIU12
Admin_Agent
Proj_Base_Verify
Prop_Temp
Docking
Prop_Sensors
Armament
GPU12b
SAU15
Admin_Agent
Admin_Agent
Defense
User_Interface
Display_Support
Proxy_X
Training
SAU11
Admin_Agent
Proj_magazine
Cannon_Loading
Travel_Lock
SAU12
SAU14
Admin_Agent
Proj_Shuttle
Proj_Verify
Load_Arm
Gun_Pointing
SAU13
Admin_Agent Admin_Agent
Shuttle_Gripper Prop_Shuttle
Prop_Conveyor Ammo_Transfer
Proj_Tracking
Resupply
Resupply_Fire Travel_Lock
Ammo_Translator
19
Crusader Software Architecture
Approach


Architecture is embodied in
the design patterns that
have been implemented
Key software architecture
patterns




SigAda - 2001
Layers
Proxy
Publish-Subscribe
(Observer)
Monitor & Control
(control interfaces)
Crew Interface
Offboard Test & Training
Embedded Support
Mobility
«Global»
Interface Services
Survivability
Command & Control
Resupply
«Global»
Peripheral Services
«Global»
Utilities
Armament
«Global»
RTCOE Services
Battlefield
«Global»
Common Types & Abstracts
Bindings & Drivers
Layers pattern arranges the software
into logically related packages that
are organized in a hierarchical,
client-server fashion
20
Cooperating Patterns




SigAda - 2001
Framework contains
cooperating patterns
Patterns form a context for
application development
Patterns are realized using
object technology
(abstract classes)
Patterns are optimized for
the Crusader domain
(ground vehicle systems)
User Interface
(Model-ViewController Pattern)
Mode and State
Management
(Monitor and
Control Pattern)
System
Management
(Monitor and Control
Pattern)
Software
Organization
(Layers Pattern)
Communication
(Proxy Pattern,
Observer Pattern)
21
Crusader Architecture Style (1)

Middleware: Real-Time
Common Operating
Environment






SigAda - 2001
Process and thread
management
Time services
Configuration
Resource management
Data logging
Communication services
Application
RTCOE System Services
(Extension of ADA95
Runtime)
Ada95 Runtime &
Predefined Library
Other COTS SW
Lynx Operating System
Hardware
22
Crusader Architecture Style (2)

Communication Patterns



Proxy: Introduced to
facilitate communication
between objects in
different threads and
processes
Publish/Subscribe:
Introduced to provide an
efficient means for all
client objects to be
notified of a server
object’s state change
Messaging code generated
automatically from O-O
model
Process #1
Proxy
Process #2
Client
Remote Proxy
(Server)
<<interface>>
Local Proxy
Proxy Class Diagram
Subscriber
A
Publisher
B
Publisher
-some_data : attribute
Publish/Subscribe Class Diagram
SigAda - 2001
23
Crusader Architecture Style (3)

Monitor & Control Pattern


Hierarchy of Supervisor Objects
Provides design pattern for
managing groups of
cooperating software
components safely and
efficiently
Manages startup, shutdown,
and reconfiguration
Vehicle Supervisor
Armament Supervisor
Resupply Supervisor
Automotive Control Supervisor
Power Distribution Supervisor
External Communication Supervisor
Vehicle Sensors Supervisor
Training Supervisor
Performance Support Supervisor
Mission Supervisor
Supervisor
Supplies Supervisor
Armament
Supervisor
Vehicle
Supervisor
Order
Fire Control Supervisor
Situation Awareness Supervisor
Navigation Supervisor
Vehicle
Capability
Vehicle
State
Operational
Interrupts
Armament
Capability
Armament
State
Armament
Order
Defense Supervisor
Tactical Data Supervisor
SigAda - 2001
24
Crusader Framework


Crusader software applications “plug into” the
framework
The framework consists of:


A library of domain-specific components (RTCOE)
A set of interacting and supporting design patterns


Abstract classes are used to create instances of the patterns
Service components that are plug-replaceable by similar
components


External communications
Peripheral services (IRU, GPS, Environment Controls, etc.)
The software architecture infrastructure forms
the real-time framework
SigAda - 2001
25
Crusader Real-Time COE
CRUSADER APPLICATIONS
COMPUTER
PLATFORMS
RTCOE Application Program Interface
RTCOE
Communication Services
• Analog I/O Service
• Discrete I/O Service
• Network Sockets Service
• Stream Service
• Proxy/Publisher Service
• Message Service
Operating System Services
• Calendar Service
• Event Service
• Heap Service
• Time Service
• Process Service
• Thread Service
• Timer Service
System Services
• Configuration Service
• Transaction Service
• Data Logging Service
• Data Storage Service
• Diagnostics Service
• Fault Service
Hardware Access Services
• Motor Controller Service
• Brake Service
• Proximity Switch Service
• Resolver Service
• Solenoid Service
• Tachometer Service
OS and Device Drivers
HARDWARE
SigAda - 2001
26
Crusader Infrastructure
CRUSADER APPLICATIONS
COMPUTER
PLATFORMS
Infrastructure Application Program Interface
Crusader Infrastructure
Framework Services
RTCOE Services
Operating
Environment
Capabilities
Framework Extension
Points (Cooperative
Patterns)
Interface Services
Peripheral Services
External
Communication
Capabilities
IRU, GPS,
Power Distribution,
Environment Control
Ballistics Kernel
OS and Device Drivers
HARDWARE
SigAda - 2001
27
Crusader Application Software
Components
Vehicle Management
Mission Applications
Mission
Management
Vehicle
Management
Training
Management
Performance
Support
Tactical
Data
Defense
Supplies &
Sustainment
Situation
Awareness
Fire
Control
Navigation
Vehicle Equipment
Automotive
Control
Armament
Equipment
Resupply
Equipment
Power
Distribution
External
Comm
Vehicle
Sensors
Infrastructure Application Program Interface
Application Components Plug Into Object-Oriented Framework
SigAda - 2001
28
Mechanistic Design Patterns

Deals with how small sets of objects collaborate
to achieve common goals



SigAda - 2001
Next tier down from architecture patterns with a focus
on design optimization
Smaller-scale patterns useful in real-time embedded
systems
These patterns take into account the strategic
architectural design decisions and refine those
decisions into more detail
29
Crusader Mechanistic Patterns (1)

Control-Loop Pattern





Crew Notification Pattern

SigAda - 2001
Used to implement servomechanism control
Control loop itself is captured using control diagrams
rather than UML diagrams
Spans Data Processor and Digital Signal Processor
computers
Optimized for performance (uses shared memory)
Used to asynchronously alert crew to events requiring
their attention
30
Crusader Mechanistic Patterns (2)

Fault Notification Pattern


Watchdog Pattern

SigAda - 2001
Provides a notification mechanism for one software
component to notify other software components that a
fault has occurred
Provides a mechanism to detect a timing fault where the
services in a computer fail to respond or respond too
late
31
Crusader Mechanistic Patterns (3)

RTCOE patterns





SigAda - 2001
Object Creation: A creational pattern that describes how
static and dynamic RTCOE objects are created
Data Exchange: A pattern that describes how clients can
interchange data with RTCOE services
Producer/Consumer: A pattern that describes how RTCOE
interfaces are separated from implementation
Notification Methods: A pattern that describes the RTCOE
notification methods used for dynamic interaction between
objects
Distributed Objects: A pattern that describes how RTCOE
distributes objects in the system
32
Experience using Architectural
based development

Maximizes software reuse on multiple levels

Design reuse within the system



Design reuse across family of vehicles



Common platform and Operating Environment (RTCOE)
Distributed design is extremely scaleable
Standardized design reduces development costs

SigAda - 2001
80% reuse of software between all vehicles
Architecture reuse potential for future programs


Common services
Common control behavior
Facilitates distributed development.
33
Experience using Architectural
based development (cont’d)

Architecture based design has proven adaptable
to change

Needs to support at least three generations of
electronics over development lifecycle.



SigAda - 2001
Each generation of electronics has fewer more powerful
computers
Supported introduction of new (Wheeled) Resupply
vehicle
Supported vehicle weight reduction (60 ton  40 ton)
with negligible impact
34
Developmental Design Evolution
1st generation
2nd generation
Fewer more powerful computers
SigAda - 2001
35
Experience using Architectural
based development (cont’d)

Model based approach facilitates Auto Code
generation

SigAda - 2001
Developed Custom Ada 95 Code generation tool using
extensibility features of Rational Rose
36
Why do Automatic Code Generation?

Generate difficult code from the Rose model.



Consistency



Production quality code.
Standard coding practice (same look & feel)
Fully exploits the Crusader Software Architecture.



SigAda - 2001
Visual modeling is often the easiest way of abstracting a
difficult problem (e.g. the layout of software interfaces)
Complex dependencies can be understood and coded
correctly.
Design reuse
Abstract patterns (e.g. supervisor)
Inter-process communications (e.g. Proxy and Publisher)
37
Types of Auto generation

Application level Software interfaces


Inter-process communications software


SigAda - 2001
Advanced code generation implements software architecture
patterns based on logical and component model.
Implementation is written just once for each pattern and then
instantiated for each different interface.
Interfaces and implementation auto generated based on
patterns and visual representation of software components
and their relationships.
38
Limitations of Auto Code generation

Given the current tools technology modeling
implementation detail is more labor intensive
than coding it manually.



SigAda - 2001
Code generation is most efficient at interface type code
and pattern based code.
Low level source code (e.g. drivers) are not
suitable
Auto code generation is of little or no benefit with
Code reuse artifacts.
39
How much did we Auto generate?
Build 2 SLOC
Non
Applicable
code
17%
Auto gen.
Capable
83%
SigAda - 2001
Build 2 Auto Generated Code
Manually
generated
Code
58%
Auto
generated
Code
42%
40
Architecture Documentation (1)
Documents for the Architecture and Design Phases
Crusader Software Architecture Document
(CSAD): Introduction and roadmap to the
components that define the system software
Software Architecture Process, Plans, and
Guidelines (SAPPG): Process, plans, and
guidelines for constructing and modeling the
software architecture
Software Design Standards (SDS):
Mandatory design guidelines for software
developers (e.g. patterns, mechanisms and
standards, )
Software Architecture Notes: Repository for
trade study artifacts and design decision
rationale
SigAda - 2001
41
Architecture Documentation (2)
Documents for the Software Construction Phase
Software Build Procedure Procedure and
guidelines for constructing the software
implementation in the development environment.
Software Ada Coding Standards: A tailoring based
on Ada 95 Quality and Style: Guidelines for
Professional Programmers (SPC-94093-CMC).
Software C/C++ Coding Standards: Based on
industry practice.
Software Architecture Notes: Repository for
decision rationale and supporting data for
project process documentation.
SigAda - 2001
42
Architecture Documentation (3)

Documentation’s focus changes over time based on the work
being performed

Architecture creation (baseline architecture)


Software Design




Focus on Software Build Procedure and Coding standards
Software Build and Artifact Management (tooling and automation for
CM)
Tuning the Software during Integration

SigAda - 2001
Focus is on design guidance (SDS)
Architecture notes to document and communicate decisions
Software Construction


Focus was on documenting the Architecture (CSAD) and Preliminary
design modeling activity (SAPPG)
Architecture Notes to document
 Setting Ada Task priorities.
 Configuring the network of process.
 Refining configuration parameters.
43
Architecture Documentation (4)
Architecture Creation
Architecture Evolution &
Design Guidance
CSAD
SDS
Architecture
Notes
SAPPG
Software Construction
SBP & Code Std’s
SigAda - 2001
Design Refinement
Architecture
Notes
44
Concluding Remarks

Large software-intensive systems need the
necessary architectural infrastructure to support
long term system maintenance


SigAda - 2001
If this is not provided, their useful life is shorter and they
are not cost effective to maintain
Systems developed using modern software
architecture methods and object technology have
attributes that address complexity, improve
maintainability, promote reuse, and reduce
software life-cycle costs
45
Contact Information
Scott Edgerton
Software Architecture Manager
Crusader Program
United Defense, L.P.
(763) 572-6156
[email protected]
SigAda - 2001
46