1 / 46

Software Architecture Team Presented by: Scott Edgerton United Defense L.P.

Software Architecture Team Presented by: Scott Edgerton United Defense L.P. Agenda. Crusader System overview Software Architecture Objectives Software Architecture Methodology Experience of using Architecture based development Software Architecture Documentation

Ava
Download Presentation

Software Architecture Team Presented by: Scott Edgerton United Defense L.P.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Architecture Team Presented by: Scott Edgerton United Defense L.P.

  2. Agenda • Crusader System overview • Software Architecture Objectives • Software Architecture Methodology • Experience of using Architecture based development • Software Architecture Documentation • Concluding remarks and Questions

  3. Resupply Port Propellant Magazine Lethal Firepower LV-100 Engine SPH XM29 Cannon Crew Cockpit Enable Information Dominated Warfare XM2002 Propellant Magazines XM2001 Resupply Port RSV-T Projectile Magazine Unmatched Survivability LV-100 Engine Crew Compartments Resupply Boom Propellant Magazine Resupply Port Fully Automated Ammo & Fuel Resupply M1075/XM2003 RSV-W Projectile Magazine PLS Truck Crew Compartment Highly Mobile Platforms Resupply Boom Projectile Magazine Crusader - A System for the 21st Century

  4. Digital Battlefield Subsystems MAN/MACHINE INTERFACE POS/NAV EMBEDDED Appliqué OPERATIONAL SOFTWARE AFATDS PLGR GPS DISPLAYS FRIEND OR FOE ID ELECTRONIC MODULES ITEM • AutoLog Book Integrated Logistic Support • Maintenance Support • Replacement Parts Diagnostic and Prognostic • Logging Diagnostic Faults • Evaluation of Diagnostic and Prognostic Faults BCIS SIP/INC/JTRS

  5. Crusader “Cockpit” Software Flat panel displays drive-by-wire full situational awareness Three crew members

  6. Crusader “Cockpit” Software Terrain Situation Analyst (TSA) • Digital Map Data • Up to 32 tactical overlays/features editor • Decision aids Tactical Data Analyst (TDA) • Manage tactical information • Guidance • Geometrics • Intelligence Diagnostic and Prognostic (DAP) • Logging diagnostic fault data • Evaluation of fault data • safety hazard detection / reporting • mission capability assessment / reporting X 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 Navigation (NAV) • Tightly coupled with Terrain Situation Analyst • Route planning weights • Threat assessment • Terrain evaluation • Route Validation and Monitoring

  7. Crusader Advanced Field Artillery System AFATDS Advanced Field Artillery Tactical Data System All Activity Focuses on the Intersection of Our Software Systems GCSS-A Global Combat Support Systems - Army FBCB2 Force Battle Command Below Brigade Systems of Systems Software

  8. System Challenges • 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

  9. SW Architecture Objectives • Object-oriented design • Distributed system • Compliance with the Joint Technical Architecture (Army) • Defines standards profile • Domain and Product-line reuse • Standardization of interface protocols

  10. Object-Oriented Approach • Advantages of an object-oriented approach are: • 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

  11. General Dynamics Land Systems United Defense, LP United Defense, GSD Honeywell United Defense, Orlando Opns Raytheon Systems Raytheon Systems. Why Emphasize Architecture? Define Product Structure • Constituent “parts” • How parts work together • Facilitate subcontracting Distributed Applications • Distribution, scalability • Quality of service • Integration and interoperation Commonality • Between vehicle platforms (SPH, RSV, RSM) • Define reuse opportunities • “Meta-process” Distributed Teams • Collaborations between companies • Multiple teams in parallel • Geographically dispersed

  12. Design Pattern Interaction Components 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

  13. (1) What the design concepts are and what they mean (4) Services provided (2) Components and communication mechanisms (3) How the components interact and change state Elements of Software Architecture Conceptual Framework Interfaces Structure Dynamic Behavior

  14. Modeling Approach • Used the Unified Modeling Language (UML) to capture our software design • Use Case View • Logical View • Component View • Concurrency View • Deployment View • A single “integrated” model is used by all geographically distributed development teams

  15. «Use Case» «Use Case» «Use Case» «Use Case» «Use Case» Init & Config Indirect Fire Move Resupply Defense «Use Case» «Use Case» «Use Case» «Use Case» «Use Case» Training Maintain Decision Aids Communicate Operate Equipment Use Case View • Ten use cases identified at the system level • Hundreds of <<uses>> and <<extends>> have been derived from these use cases.

  16. Logical View

  17. Component View • Describes organization of components • Layers, subsystems, modules • Used subsystems for reuse and configuration management • Shows the compile-time dependencies and packaging structure of the deployed system

  18. SPH Combat State SPH Live Fire Exercise State SPH Active Dry Fire State SPH Passive Dry Fire State select substate SPH Administrative SPHMaintenance Operations State State SPH Ind /Crew Training State SPH CPX/DIS State SPH Solo Dry Fire State select administrative Concurrency View Used state diagrams and sequence diagrams extensively Vehicle behavior is based on states and modes

  19. GPU11b SAIU12 SAIU11 GPU11a GPU12a SAU11 GPU12b SAU15 SAU12 SAU14 SAU13 Gateway Segmentation Subnetwork Admin_Agent Proj_magazine Cannon_Loading Travel_Lock Admin_Agent Shuttle_Gripper Prop_Conveyor Resupply Resupply_Fire Ammo_Translator Admin_Agent Prop_Shuttle Ammo_Transfer Proj_Tracking Travel_Lock Admin_Agent Defense Admin_Agent Vehicle_Env Mobility Fuze_Setter Admin_Agent User_Interface Display_Support Proxy_X Training Admin_Agent User_Interface Display_Support Proxy_X Mission_Mgmt Indirect_Fire Admin_Manager Admin_Agent User_Interface Display_Support Proxy_X Combat_ID Navigation Power_Control External_Comm Admin_Agent Proj_Base_Verify Prop_Temp Docking Prop_Sensors Armament Admin_Agent Proj_Shuttle Proj_Verify Load_Arm Gun_Pointing Deployment View

  20. Crusader Software Architecture Approach • Architecture is embodied in the design patterns that have been implemented • Key software architecture patterns • Layers • Proxy • Publish-Subscribe (Observer) • Monitor & Control (control interfaces) Layers pattern arranges the software into logically related packages that are organized in a hierarchical, client-server fashion

  21. Mode and State Management (Monitor and Control Pattern) User Interface (Model-View- Controller Pattern) System Management (Monitor and Control Pattern) Software Organization (Layers Pattern) Communication (Proxy Pattern, Observer Pattern) Cooperating Patterns • 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)

  22. Crusader Architecture Style (1) • Middleware: Real-Time Common Operating Environment • Process and thread management • Time services • Configuration • Resource management • Data logging • Communication services Application RTCOE System Services (Extension of ADA95 Runtime) Other COTS SW Ada95 Runtime & Predefined Library Lynx Operating System Hardware

  23. Subscriber Publisher Publisher A B Publish/Subscribe Class Diagram -some_data : attribute 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 Proxy Class Diagram

  24. Hierarchy of Supervisor Objects 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 Supplies Supervisor Supervisor Armament Order Fire Control Supervisor Supervisor Situation Awareness Supervisor Navigation Supervisor Defense Supervisor Armament Vehicle Vehicle Operational Armament Armament Order Capability State Interrupts Capability State Tactical Data Supervisor Crusader Architecture Style (3) • Monitor & Control Pattern • Provides design pattern for managing groups of cooperating software components safely and efficiently • Manages startup, shutdown, and reconfiguration Vehicle Supervisor

  25. 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

  26. CRUSADER APPLICATIONS COMPUTER PLATFORMS RTCOE Application Program Interface 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 RTCOE OS and Device Drivers HARDWARE Crusader Real-Time COE

  27. CRUSADER APPLICATIONS COMPUTER PLATFORMS Infrastructure Application Program Interface Crusader Infrastructure Peripheral Services IRU, GPS, Power Distribution, Environment Control Ballistics Kernel Framework Services Framework Extension Points (Cooperative Patterns) Interface Services External Communication Capabilities RTCOE Services Operating Environment Capabilities OS and Device Drivers HARDWARE Crusader Infrastructure

  28. Training Management Vehicle Management Performance Support Navigation Mission Management Supplies & Sustainment Fire Control Tactical Data Defense Power Distribution Situation Awareness Resupply Equipment Automotive Control Armament Equipment External Comm Vehicle Sensors Infrastructure Application Program Interface Application Components Plug Into Object-Oriented Framework Crusader Application Software Components Vehicle Management Mission Applications Vehicle Equipment

  29. Mechanistic Design Patterns • Deals with how small sets of objects collaborate to achieve common goals • 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

  30. Crusader Mechanistic Patterns (1) • Control-Loop Pattern • 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) • Crew Notification Pattern • Used to asynchronously alert crew to events requiring their attention

  31. Crusader Mechanistic Patterns (2) • Fault Notification Pattern • Provides a notification mechanism for one software component to notify other software components that a fault has occurred • Watchdog Pattern • Provides a mechanism to detect a timing fault where the services in a computer fail to respond or respond too late

  32. Crusader Mechanistic Patterns (3) • RTCOE patterns • 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

  33. Experience using Architectural based development • Maximizes software reuse on multiple levels • Design reuse within the system • Common services • Common control behavior • Design reuse across family of vehicles • 80% reuse of software between all vehicles • Architecture reuse potential for future programs • Common platform and Operating Environment (RTCOE) • Distributed design is extremely scaleable • Standardized design reduces development costs • Facilitates distributed development.

  34. 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. • 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

  35. Developmental Design Evolution 1st generation 2nd generation Fewer more powerful computers

  36. Experience using Architectural based development (cont’d) • Model based approach facilitates Auto Code generation • Developed Custom Ada 95 Code generation tool using extensibility features of Rational Rose

  37. Why do Automatic Code Generation? • Generate difficult code from the Rose model. • 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. • Consistency • Production quality code. • Standard coding practice (same look & feel) • Fully exploits the Crusader Software Architecture. • Design reuse • Abstract patterns (e.g. supervisor) • Inter-process communications (e.g. Proxy and Publisher)

  38. Types of Auto generation • Application level Software interfaces • Advanced code generation implements software architecture patterns based on logical and component model. • Inter-process communications software • 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.

  39. Limitations of Auto Code generation • Given the current tools technology modeling implementation detail is more labor intensive than coding it manually. • 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.

  40. How much did we Auto generate?

  41. 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 Architecture Documentation (1)

  42. 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.

  43. Architecture Documentation (3) • Documentation’s focus changes over time based on the work being performed • Architecture creation (baseline architecture) • Focus was on documenting the Architecture (CSAD) and Preliminary design modeling activity (SAPPG) • Software Design • Focus is on design guidance (SDS) • Architecture notes to document and communicate decisions • Software Construction • Focus on Software Build Procedure and Coding standards • Software Build and Artifact Management (tooling and automation for CM) • Tuning the Software during Integration • Architecture Notes to document • Setting Ada Task priorities. • Configuring the network of process. • Refining configuration parameters.

  44. CSAD SDS Architecture Notes SAPPG Software Construction Design Refinement Architecture Notes SBP & Code Std’s Architecture Documentation (4) Architecture Creation Architecture Evolution & Design Guidance

  45. Concluding Remarks • Large software-intensive systems need the necessary architectural infrastructure to support long term system maintenance • 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

  46. Contact Information Scott Edgerton Software Architecture Manager Crusader Program United Defense, L.P. (763) 572-6156 Scott_Edgerton@UDLP.com

More Related