software archiecture lecture04

31
A-7E Avionics System: A Case Study in Utilizing A Case Study in Utilizing Architectural Structures

Upload: luktalja

Post on 29-Nov-2014

315 views

Category:

Education


1 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Software archiecture   lecture04

A-7E Avionics System: A Case Study in Utilizing A Case Study in Utilizing Architectural Structures

Page 2: Software archiecture   lecture04

AgendaAgenda

• A case study of an architecture designed by engineering and specifying 3 specific architectural engineering and specifying 3 specific architectural structures.

• We will see how these structures complement each other to provide a complete picture of how the other to provide a complete picture of how the system works

• We will see how certain qualities of the system are • We will see how certain qualities of the system are affected by each one.

Page 3: Software archiecture   lecture04

A-7E Corsair IIA-7E Corsair II

• It is a single-seat, carrier-based attack aircraft used by the U.S. Navy throughout the 1960s, 1970s, and by the U.S. Navy throughout the 1960s, 1970s, and 1980s.

Page 4: Software archiecture   lecture04

A-7E Corsair IIA-7E Corsair II

• The A-7C (earlier version), was the very first production aircraft in the world to be equipped with production aircraft in the world to be equipped with an onboard computer to help the pilot with navigation and "weapon delivery"

The A-7E's onboard computer is a small, special-• The A-7E's onboard computer is a small, special-purpose IBM machine for which no compiler exists; programming is in assembly language onlyprogramming is in assembly language only

• The computer has special registers connected to A-D/D-A converters that let it receive and send data to almost two dozen devices in the aircraft's to almost two dozen devices in the aircraft's avionics suite.

Page 5: Software archiecture   lecture04

Requirements and Qualities

Page 6: Software archiecture   lecture04

Software FunctionalitySoftware Functionality

• The A-7E software is responsible for reading sensors and updating cockpit displays that help the pilot drop updating cockpit displays that help the pilot drop weapons on a target.

• The pilot communicates the location of a ground target (or a navigational waypoint) to the software in a number of ways, including the following:(or a navigational waypoint) to the software in a number of ways, including the following:

▫ Keying in its latitude and longitude via the keypad

▫ Slewing the map using a joystick until its coordinates are under the center crosshairs and then "designating" ▫ Slewing the map using a joystick until its coordinates

are under the center crosshairs and then "designating" it by pushing a special button on the control stick

▫ Aiming the forward-looking radar to the point and designating itdesignating it

▫ Slewing a special symbol on the heads-up display until it overlays the point of interest on the ground and then designating itthen designating it

Page 7: Software archiecture   lecture04

Software FunctionalitySoftware Functionality

• The software then provides navigational information (direction, distance, time to go) and directional (direction, distance, time to go) and directional cues on the heads-up display that take the aircraft to the designated location.

The software has at least five direct and indirect • The software has at least five direct and indirect ways to calculate the aircraft's current altitude

▫ Example: a trigonometric scheme using the ▫ Example: a trigonometric scheme using the range and elevation angle of the forward-looking radar as components of a triangle

• There are more than 20 weapon delivery modes, all • There are more than 20 weapon delivery modes, all demanding in terms of the real-time calculations (repeated 25 times every second) necessary to (repeated 25 times every second) necessary to maintain the A-7E's bombing accuracy

Page 8: Software archiecture   lecture04

Figure 3.3 Calculation of altitudeFigure 3.3 Calculation of altitude

Page 9: Software archiecture   lecture04

Quality AttributesQuality Attributes

• The architecture we will present is not the architecture for the original software but that for a architecture for the original software but that for a redesign project launched by Navy software engineers• The qualities that the software system was • The qualities that the software system was

expected to have included real-time performance and modifiability for expected changes. • Specifically, the performance requirements were • Specifically, the performance requirements were

stated in terms of updates per second of the A7-E's displays and weapon delivery calculations. • The modifiability requirements dealt with making • The modifiability requirements dealt with making

changes to the weaponry, the platform, the symbology on the display, and the addition of new input through the keypadinput through the keypad

Page 10: Software archiecture   lecture04

ScenariosScenarios

• The system was constructed beginning in 1977 for the naval aviators who flew the A-7E aircraft the naval aviators who flew the A-7E aircraft

• The developing organization was the software engineering group at the U.S. Naval Research Laboratory.Laboratory.

• The developers were creating the software to test their belief that certain software engineering their belief that certain software engineering strategies were appropriate for high-performance embedded real-time systems.

▫ information hiding ▫ information hiding

▫ cooperating sequential processes

Page 11: Software archiecture   lecture04

ScenariosScenarios

• The architects included one of the authors of this book (Paul Clements) and one of the leaders in the book (Paul Clements) and one of the leaders in the development of software engineering principles (David Parnas)

There was no compiler available for the target • There was no compiler available for the target platform.

Page 12: Software archiecture   lecture04

Relationship to the Architecture Business CycleBusiness Cycle

Page 13: Software archiecture   lecture04

A-7E Avionics System ArchitectureA-7E Avionics System Architecture

• The architecture for the A-7E avionics system is centered around three architectural structures:centered around three architectural structures:

▫ Decomposition, a structure of modules

▫ Uses, a structure of modules▫ Uses, a structure of modules

▫ Process, a structure of components and connectors

• We will discuss each in turn• We will discuss each in turn

Page 14: Software archiecture   lecture04

Table 3.1: Architectural StructuresTable 3.1: Architectural Structures

Structure Elements Relationsamong

Has Influence overamong Elements

Module Decomposition

Modules (implementation

Is a submodule of; shares a secret with

Ease of changeDecomposition (implementation

units)shares a secret with

Uses Procedures Requires the correct presence of

Ability to field subsets and develop incrementally

Process Processes; thread Synchronizes with; Schedulability; Process Processes; thread of procedures

Synchronizes with; shares CPU with; excludes

Schedulability; achieving performance goals through parallelism

Page 15: Software archiecture   lecture04

Decomposition - Information HidingDecomposition - Information Hiding

• In case if a device such as an aircraft altitude sensor is likely to be replaced over the life of an sensor is likely to be replaced over the life of an avionics program

• The information-hiding principle makes the details of interacting with that device the secret of one of interacting with that device the secret of one module

• Information hiding is enforced by requiring that • Information hiding is enforced by requiring that modules interact only via a defined set of public facilities—their interfaces

• Each module provides a set of access procedures• Each module provides a set of access procedures

Page 16: Software archiecture   lecture04

Decomposition – Specific goalsDecomposition – Specific goals

• Each module's structure should be simple enough to be understood fully.to be understood fully.

• It should be possible to change the implementation of one module without knowledge of the implementation of other modules and without implementation of other modules and without affecting the behavior of other modules.

• It should be possible to make a major software • It should be possible to make a major software change as a set of independent changes to individual modules

Page 17: Software archiecture   lecture04

Decomposition – module guideDecomposition – module guide

• The documentation of the decomposition structure is sometimes called a module guide.is sometimes called a module guide.

• The guide states the criteria used to assign a particular responsibility to a module

• We arranges the modules in tree structure, So we can find the necessary information without searching through unrelated documentationsearching through unrelated documentation

• The guide does not describe any runtime relationship among the modules

• The guide does not talk about how modules interact • The guide does not talk about how modules interact with each other while the system is executing

Page 18: Software archiecture   lecture04

Achieves Quality GoalsAchieves Quality Goals

• How the A-7E Module Decomposition Structure Achieves Quality GoalsAchieves Quality Goals

Goal How Achieved

Ease of change to: weapons, platform, symbology, input

Information hiding

Understand anticipated changes Formal evaluation procedure to take Understand anticipated changes Formal evaluation procedure to take advantage of experience of domain experts (Because a designer might not have had all of the relevant experience)

Assign work teams so that their interactions were minimized

Modules structured as a hierarchy; each work team assigned to a second-level module and all of its descendants

Page 19: Software archiecture   lecture04

A-7E Module Decomposition StructureStructure• The decomposition tree is described beginning with the

three highest-level modules.three highest-level modules.

• These are motivated by the observation that changes tend to come from three areas

▫ Hardware-Hiding Module▫ Hardware-Hiding Module� Hides the procedures that need to be changed if any part of

the hardware is replaced by a new unit with a different hardware/software interface but with the same general capabilities.capabilities.

▫ Behavior-Hiding Module� Hides procedures that need to be changed if there are

changes in requirements affecting the required behavior.changes in requirements affecting the required behavior.

▫ Software Decision Module� Hides software design decisions that are based on

mathematical theorems, physical facts, and programming considerationsmathematical theorems, physical facts, and programming considerations

Page 20: Software archiecture   lecture04

A-7E Module guideA-7E Module guide

• The module guide goes on to explain how conflicts among these categories are arbitrated by a among these categories are arbitrated by a complete and unambiguous requirements specification

e.g., is a required algorithm part of the behavior ▫ e.g., is a required algorithm part of the behavior or a software decision?

• The module guide then describes the second-level & • The module guide then describes the second-level & third-level decomposition

• Notice that many of the Device Interface modules have the same names as Function Driver moduleshave the same names as Function Driver modules

Page 21: Software archiecture   lecture04

Hardware-Hiding Module

Extended Computer ModuleData ModuleInput/Output Module

Behavior-Hiding Module

Function Driving ModuleAir Data Computer ModuleAudible Signal ModuleInput/Output Module

Computer State ModuleParalleslism Control ModuleProgram ModuleVirtual Memory ModuleInterrupt Handler Module

Audible Signal ModuleComputer Fail Signal ModuleDoppler Radar Set ModuleFlight Information Display ModuleForward Looking Radar ModuleHead-Up Display ModuleInterrupt Handler Module

Timer Module

Device Interface ModuleAir Data Computer ModuleAngle of Attack Sensor ModuleAudible Signal Device Module

Head-Up Display ModuleInertial Measurement Set ModulePanel ModuleProjected Map Display Set ModuleShipboard Inertial Navigation System ModuleVisual Indicator ModuleWeapon Release System Module

Audible Signal Device ModuleComputer Fail Device ModuleDoppler Radar Set ModuleFlight Information Displays ModuleForward Looking Radar ModuleHead-Up Display ModuleInertial Measurement Set Module

Weapon Release System ModuleGround Test Module

Shared Services ModuleMode Dertermination ModulePanel I/O Support ModuleInertial Measurement Set Module

Input/Output Representation ModuleMaster Function Switch ModulePanel ModuleProjected Map Display Set ModuleRadar Altimeter Module

Panel I/O Support ModuleShared Subroutine ModuleStage Director ModuleSystem Value Module

Radar Altimeter ModuleShipboard Inertial Navigation System ModuleSlew Control ModuleSwitch Bank ModuleTACAN ModuleVisual Indicators ModuleVisual Indicators ModuleWaypoint Information System ModuleWeapon Characteristics ModuleWeapon Release System ModuleWeight on Gear Module

Page 22: Software archiecture   lecture04

Software Decision Module

Application Data Type ModuleNumeric Data Type ModuleNumeric Data Type ModuleState Transition Event Module

Data Banker ModuleSingular Values ModuleComplex Event Module

Filter Behavior ModuleFilter Behavior Module

Physical Models ModuleAircraft Motion ModuleEarth Characteristics ModuleHuman Factors ModuleHuman Factors ModuleTarget Behavior ModuleWeapon Behavior Module

Software Utility ModulePower-Up Initialization ModuleNumerical Algorithms Module

System Generation ModuleSystem Generation Parameter ModuleSupport Software Module

Numerical Algorithms Module

Page 23: Software archiecture   lecture04

Uses –Uses RelationUses –Uses Relation

• The concept behind the uses structure is the uses relation.relation.

• In practice this relation is similar to but not quite the same as the calls relation.

▫ Procedure A is simply required to call procedure B in its specification, but the future computation performed by A will not depend on what B doesperformed by A will not depend on what B does

• The unit of the uses (or allowed-to-use) structure is the access procedure.

• In practice all of the procedures of a module may • In practice all of the procedures of a module may share usage restrictions. Hence, the name of a module might appear in the uses structure.module might appear in the uses structure.

Page 24: Software archiecture   lecture04

Achieves Quality GoalsAchieves Quality Goals

• How the A-7E Uses Structure Achieves Quality GoalsGoals

Goal How Achieved

Incrementally build and test system functions

Create "is-allowed-to-use" structure for programmers that limits procedures each can use

Design for platform change Restrict number of procedures that use Design for platform change Restrict number of procedures that use platform directly

Produce usage guidance of manageable size

Where appropriate, define uses to be a relationship among modules

Page 25: Software archiecture   lecture04

Excerpt from the A-7E Allowed-to-Use SpecificationUse SpecificationUsing procedures: A procedure in… .. Is allowed to use any procedure in …

EC: Extended Computer Module None

DI: Device Interface Module

ADC: Air Data Computer

EC.DATA, EC.PGM, EC.IO, EC.PAR, AT.NUM, AT.STE, SUPM.ECMADC: Air Data Computer

IMS: Inertial Measurement Set

PM.ECM

PM.ACM

FD: Function Driver Module EC.DATA, EC.PAR, EC.PGM, AT.NUM, AT.STE, FD: Function Driver Module

ADC: Air Data Computer Functions

EC.DATA, EC.PAR, EC.PGM, AT.NUM, AT.STE, SU, DB.SS.MODE, DB.SS.PNL.INPUT, DB.SS.SYSVAL, DB.DI

DB.DI.ADC, DI.ADC, FB

IMS: IMS Functions

PNL: Panel Functions

DB.DI.IMS, DI.IMS

EC.IO, DB.SS.PNL.CONFIG, SS.PNL. FORMAT, DI.ADC, DI.IMS, DI.PMDS, DI.PNL

Page 26: Software archiecture   lecture04

Excerpt from the A-7E Allowed-to-Use SpecificationUse SpecificationUsing procedures: A procedure in… .. Is allowed to use any procedure in …

SS: Shared Services Module

PNL: Panel I/O Support

EC.DATA, EC.PGM, EC.PAR, AT.NUM, AT.STE, SU

DB.SS.MODE, DB.DI.PNL, DB.DI.SWB, SS.PNL.CONFIG, DI.PNLSS.PNL.CONFIG, DI.PNL

AT: Application Data Type Module

NUM: Numeric Data Types

EC.DATA, EC.PGM

None additionalNUM: Numeric Data Types

STE: State Transition Events

None additional

EC.PAR

Page 27: Software archiecture   lecture04

ProcessProcess

• A process is a set of programming steps that are repeated in response to a triggering event or to a repeated in response to a triggering event or to a timing constraint.

• It has its own thread of control, and it can suspend itself by waiting for an event (usually by invoking itself by waiting for an event (usually by invoking one of the event-signaling programs on a module's interface).interface).

• The Extended Computer Module presents a virtual programming interface that features multiprocessing capabilities , because A-7E multiprocessing capabilities , because A-7E computer is a uniprocessor

Page 28: Software archiecture   lecture04

Process StructuresProcess Structures

• The process structure emerged after the other structures had been designed. structures had been designed. ▫ Function Driver procedures were implemented as

processes. ▫ Other processes computed time-consuming ▫ Other processes computed time-consuming

calculations in the background so that a value would always be available.

• Two kinds of information were captured in the • Two kinds of information were captured in the process structure. ▫ The first documented what procedures were

included in the body of each process. included in the body of each process. ▫ The second kind of information in the process

structure documented which processes could not execute simultaneously. structure documented which processes could not execute simultaneously.

Page 29: Software archiecture   lecture04

Function driver processes structureFunction driver processes structure

Periodic process: do every 40 milliseconds

- Call other modules ‘ access procedures to gather the values of all - Call other modules ‘ access procedures to gather the values of all relevant inputs

- Calculate the resulting output value

- Call the appropriate Device Interface procedure to send the output - Call the appropriate Device Interface procedure to send the output value to the outside world

End periodic process

Demand process

- Await triggering event

- Calculate the resulting output outcome- Calculate the resulting output outcome

- Call the appropriate Device Interface procedure to trigger the action in the outside world

End demand processEnd demand process

Page 30: Software archiecture   lecture04

Achieves Quality GoalsAchieves Quality Goals

• How the A-7E Process Structure Achieves Quality GoalsGoals

Goal How Achieved

Map input to output Each process implemented as cycle that samples, inputs, computes, and presents output

Maintain real-time constraints Identify process through process Maintain real-time constraints Identify process through process structure and then perform offline scheduling

Provide results of time-consuming calculations immediately

Perform calculations in background and return most recent value when queried

Page 31: Software archiecture   lecture04

SummarySummary

• This chapter described the architecture of a highly capable avionics system in terms of three related capable avionics system in terms of three related but quite different structures.▫ A module decomposition structure describes

design-time relations among its components, design-time relations among its components, which are implementation units that can be assigned to teams. ▫ A uses structure describes runtime usage ▫ A uses structure describes runtime usage

relations among its components, which are procedures in modules. From it, a picture of a layered architecture emerges. layered architecture emerges. ▫ The process structure describes the parallelism of

the system and is the basis for assignment for the physical hardwarephysical hardware