180 likes | 838 Views
Ada, CMM Level 4, and the C-130J Aircraft. Presentation for SIGAda 2002 University of Houston, Clear Lake Tuesday, December 10, 2002 Richard Conn, C-130J Software Process Engineer. Contents. About the C-130J Aircraft Specifications Applications Software Associated with the C-130J Aircraft
E N D
Ada, CMM Level 4, and the C-130J Aircraft Presentation for SIGAda 2002 University of Houston, Clear Lake Tuesday, December 10, 2002 Richard Conn, C-130J Software Process Engineer
Contents • About the C-130J Aircraft • Specifications • Applications • Software Associated with the C-130J Aircraft • Mission Computer • Ground-Based Data System • Software Development Environment • Languages and Tools • Achieving Capability Maturity Through Automation Lockheed Martin Aeronautics Company at Air Force Plant 6 In Marietta, GA
About the C-130J Aircraft First named “Hercules,” the C-130 has become a legend, with more than 2,100 C-130’s built and purchased by over 60 nations in dozens of variations. The C-130: • Carries troops, vehicles, and armaments into battle • Drops paratroopers and supplies • Serves as airborne and ground refuelers • Provides emergency and humanitarian relief (even acting as hospital ships) • Does airborne early warning and maritime surveillance (it even flies into hurricanes) First delivery of the C-130J was to the Royal Air Force • The new C-130J looks like the original on the outside, but it is vastly improved: • 21% faster, 40% higher, 40% longer range • Reduced manpower (aircrew of 2 instead of 5), operating costs, support costs, lifecycle costs • A new propulsion system (29% more thrust with 15% more fuel efficiency) • Advanced avionics technology – 50 World’s Records!
About the C-130J - Advanced Avionics Technology • Four multifunctional heads-down Liquid Crystal Display (LCD) instrument readouts for • Aircraft Flight Control • Operating Internal Systems • Navigation • Two holographic heads-up displays (HUDs) compatible with night vision imaging systems • Full-Authority Digital Aircraft Engine Control (FADEC) • Two Mission Computers (MCs) and two backup Bus Interface Units (BIUs) provide dual-redundant aircraft control with integrated diagnostics The State-of-the-Art Cockpit of the C-130J • Ground-Based Data System (GBDS) for aircraft analysis and maintenance on the ground • More than 50 Computer Software Configuration Items (CSCIs)
Block 2 - the 382J Aircraft The 382J Aircraft is the base class upon which the C-130J is based The 382J Aircraft received FAA Type Certification Block 3 - the basic C-130J Aircraft Inherits from the 382J Aircraft Block 2 and Block 3 Domain Engineering was performed since the early 1990’s Block 4 - the Variants of the basic C-130J Aircraft Unique versions of the C-130J modified for several customers, including, but not limited to: United States Air Force (2 Variants) Royal Air Force - United Kingdom Royal Australian Air Force Block 5 – Maintenance and ECPs as well as more Variants Customer needs change More customers, such as Denmark Each Block (and, in the case of Block 4 and 5, each Variant) is divided into: Air Vehicle CSCIs - provide central computing (MC and BIU) and subsystem (e.g., FADEC) software on the aircraft Support Systems CSCIs - support ground-based laboratories and data collection and analysis system (GBDS) Training Systems CSCIs - support training the air crew and aircraft maintenance personnel Classes of Aircraft Software
C-130J CSCI Hierarchy C-130J CSCIs Air Vehicle (AV) CSCIs Support Systems CSCIs Training Systems CSCIs • MC and BIU Operational Flight Program (OFP) CSCIs • Subsystem CSCIs • Ground-Based Data System (GBDS) CSCIs • Large Aircraft Digital Avionics Simulation and Systems Integration Laboratory (LADASSIL) CSCIs • Aircrew CSCIs • Maintenance CSCIs There are more than 50 Air Vehicle CSCIs for each Block.
The C-130J Air Vehicle Avionics Architecture Two Mission Computers (MCs) Two Bus Interface Units (BIUs) A number of aircraft subsystem devices known generally as Line-Replaceable Units (LRUs) LMAC has developed the MC Operational Flight Program (OFP) and the BIU OFP CSCIs Perform interconnection and intercommunication between other computing elements Central repository for information on the aircraft subsystems LMAC and 26 suppliers have developed the LRUs and their internal software The MC OFP and the BIU OFP CSCIs interact with the 6 Ground-Based Data System (GBDS) CSCIs developed by LMAC Ground Maintenance Program Application Processing (GMPAP) CSCI Ground Maintenance Program Special Processing (GMPSP) CSCI Operational Maintenance Program Mission Computer (OMP-MC) CSCI Operational Maintenance Program Portable Maintenance Aid (OMP-PMA) CSCI Router CSCI Memory Loader Verifier (MLV) CSCI Air Vehicle CSCIs - Introduction
Management of such a complex set of software created by LMAC and a myriad of suppliers is a formidable task The management starts with the Tier I Software Development Plan (SDP): Is the controlling document for managing the software aspects of the C-130J program Overviews the management and technical processes necessary to satisfy the requirements of the C-130J program Provides directions for creating the Tier II SDPs, provided by LMAC and each supplier LMAC has created two Air Vehicle Tier II SDPs - one for the MC and BIU OFP CSCIs and one for the 6 GBDS CSCIs These SDPs address management and technical issues, including, but not limited to, the issues of: overall management aircraft safety and security software process definition and management Requirements- and reuse-oriented software processes have been developed in accordance with the LMAC Standard Software Process Framework (SSPF), which is compliant with SEI CMM Level 3, ISO 9001, and IEEE/EIA 12207 SDPs - Tier I and Tier II
Level 1 C-130J MC Software Development Process System Definition Software Requirements Software Design Code/ Unit Testing System Maintenance Requirements-Based Testing Test Readiness Review Qualification Test Qualification Test Preparation Software Integration SEPD Build Formal Qualification Test Formal Qualification Test Preparation Documentation Production Software Delivery Each process in these boxes is expanded in a Level 2 diagram (not shown in this presentation). There are over 110 processes total (21 November 2002).
Domain Engineering (DE) is performed on the C-130J program (has been since the early 1990’s) The C-130J domain was defined in terms of the Air Vehicle, Support, and Training Systems, emphasizing the MC and BIU OFP CSCIs: MC and BIU Architecture definition was designed to support the addition, removal, and modification of classes of LRU devices to the aircraft Design templates for 5, and now 8, classes of devices were created and used; today, we call this Template-Based Design (TBD) and use the templates to add new devices/LRUs Ada-based Design Approach for Real-Time Systems (ADARTS) was used to create the templates Requirements-Based Engineering (RBE) is performed on the C-130J program Requirements are defined in a more precise, specific form using CoRE (Consortium Requirements Engineering) tables Qualification criteria (testability) for requirements is defined when the requirements themselves are defined This leads to Requirements-Based Testing (RBT) DE, ADARTS, TBD, RBE, RBT, and CoRE are employed with the support of the Software Productivity Consortium (SPC) Software Development and Reuse
Process changes and product lifecycles are managed using an automated rule-based, closed-loop change control process driven by the Process Configuration Management System (PCMS) tool All work products, not just baselined products, are controlled The program personnel are given roles that specify their abilities to affect the products being controlled Parallel development efforts are facilitated (8 C-130J Blocks/Variants are currently in various stages of development) Accurate, current, and complete status accounting is a by-product of the use of the PCMS-based process The automated process backed by tool support reduces administrative support and clerking overhead Electronic Online Software Change Requests (OSCRs) and an electronic Software Development Change Control (SDCC) board are a key part of this process OSCRs are controlled like any other work product, and they have a lifecycle Process Change and Product Lifecycle Management Requirements Implementation Integration and Testing Submit Code Implementation Analysis Ready for Build SDCC Review Hold OSCR Lifecycle Closed Reject
Corporate Perspective 95% 100% Committed Costs 85% 90% 500-1000X 80% 70% 70% Cost to Extract Defects Operations Through Disposal 20-100X Production/ Test Phase 60% 50% Cumulative Percentage Life Cycle Cost 3-6X 40% 100% 30% Development Design Phase 50% 20% Concept Phase 20% 10% 15% 8% 0% Time Full Program Expenditures Presented at the Lockheed Martin Joint Symposium 2001 by Dr. Vance Coffman, Chairman
Software Development Environment – Trapping Defects Through Lines of Defense Ada Compilers and Tool Platforms RTM and Requirements Analysis Requirements Code Path Coverage Analyzer Software Product Evaluations Test Scripts SPARK Examiner and Robustness Analyzers Processes and Metrics Other Products Requirements-Based Testing and Lab Tests Audits/Assessments
Automated Software Product Evaluations Preparation/ Conduct Review Planning Inspection/ Conclude Rework Follow-Up and Lock Overview 3rd Hour/ Process Improvement = optional Process Flow
Automated SPEs (continued) Client Side Server Side SPE Controller SPE Data Store Containing Several Datasets IWeb Browser (IE or Netscape) IPT Configuration SPE Starter 4 with Code Counter Ft Worth (Automet ) SPE Information Assistant IPT Configuration
Automated SPEs (concluded) Web Browser, SPE Starter 4, or IA (Data Collection) Client Side – PCs and Suns Information Assistant (IA) (Data Analysis) Windows or UNIX Operating System (SS4, IA run only under Windows) UNIX Operating System HTTP Daemon (Web Server) DCS3 SPE Controller Server Side - Sun DCS3 Data Store
Questions? Looking for More Information? • LM and LMAC Public Websites • http://www.lockheedmartin.com • http://www.lmaeronautics.com/ • My University Websites • http://unicoi.kennesaw.edu/~rconn • Paper in Crosstalk • Paper in IEEE Software • http://cs.spsu.edu/rconn • My email • Richard.L.Conn@lmco.com