IOTPA7-196

CarngeMellon Uriversaty

Software Engineering Institute

inertial Navigation Systemsimulator:

D ej Behavioral Specification

IR194 J' 000.3

85 ~ 21060f\

Technical Report

ESD-TR-87-1 96

October 1987

Inertial Navigation System Simulator:Behavioral Specification

Stefan F. LandherrResident Affiliate

Mark H. KleinAda Embedded Systems Testbed Project

Ac-Cesion F or]

DT C I A8li:Lj~u;, - ced Li

JL L'', zvI

A-1 Approved for public release.I Distribution unlimited.

Software Engineering InstituteCarnegie Mellon University

Pittsburgh, Penn~sylvania 15213

This technical report was prepared for the

SEI Joint Program OfficeESD/XRSHanscom AFB, MA 0 1731

The ideas and findings in this report should not be construed as an official DoDposition. ft is published in the interest of scientific and technical informationexchange.

Review and Approval

This report has been reviewed and is approved for publication.

FOR THE COMMANDER

Daniel BurtonSEI Joint Program Office

This work is sponsored by the U.S. Department of Defense.

Copyright 0 1987 by the Software Engineering Institute

This document is available through the Defense Technical Information Center. OTIC provides access to and transfer ofsaienthic and technical information for DoD personnel, DoD contractors and potential contractors, and other U.S. Governmentagency personnel and their contractors. To obtain a copy, please contact DTIC direcly: Defense Technical InformationCenter, Attn: FORA, Cameron Station, Alexandria, VA 2230446145.Copies of this document are also available through the National Technical Information Setvioes. For information on ordering,please contact NTIS directly: National Technical Information Services, U.S. Department of Commerce, Springfield, VA 22161

Ada is a registered trademark of the, U.S. Department of Defense. Ada Joint Program Office. MicroVAX, VAX, VAXELN. and VMSare trademarks of Digital Equipment Corporation

L-

Table of Contents1. Introduction 1

2. Input/Output Interfaces 32.1. Communications Link 3

2.1.1. Logical Interface 3_ 2.1.2. External Function (EF) Codes 4

2.1.3. Message Types and Formats 42.2. Console Keyboard 8

2.2.1. Logical Interface 82.2.2. Command Syntax 8

2.3. Console Screen 112.3.1. Logical Interface 112.3.2. Screen Layout 11

2.4. Disk File 122.4.1. Logical Interface 122.4.2. Recording Format 12

3. External Behavior 173.1. Communications Link 173.2. Console Keyboard 203.3. Console Screen 21

* 3.3.1. Command Window 213.3.2. Alert Window 213.3.3. System Status Window 243.3.4. Periodic Display Window 24

3.4. Disk File Interface (Data Extraction) 24

4. Internal Behavior 254.1. Motion Calculations 25

4.1.1. Update Ship Attitude 254.1.2. Update Ship Velocity 254.1.3. Update Ship Position 25

4.2. Runtime Built-In Test 25

5. Initialization, Control, and Termination 275.1. Program Preparation and Initiation 285.2. Initial Built-In Tests 28

5.2.1. Arithmetic Capability Test 285.3. Program Initialization 29

5.3.1. Device Initialization 295.3.2. Motion Simulator Parameter Initialization 295.3.3. Other Initialization 29

5.4. Program Control 295.5. Program Termination 30

CMUISEI-87-TR-33 I

Glossary 31

References 33

Appendix A. Timing Constraints 35

Appendix B. Communications Link Statecharts 37B.a. Summary of Statechart Syntax 37B.b. Master Communications Link Statechart 39 .B.c. Enabling Communications Statechart 40B.d. Receiving Enabling Test Message Statechart 41B.e. Sending Enabling Test Message Statechart 42B.f. Communications Enabled Statechart 43B.g. Receiving Message from External Computer Statechart 45B.h. Sending Message to External Computer Statechart 46

II CMU/SEI-87-TR-33

List of Figuresn Figure 2-1: Inertial Navigation System Computer Interfaces 3

Figure 2-2: Screen Windows 11Figure 2-3: Detailed Screen Layout 12Figure 3-1: Communications Protocol: Summary 18Figure 5-1: Program Timeline 27

CMU/SEI-87-TR-33 Iii

4i

IV CMUISEI-67-TR-33

61

List of Tables

Table 2-1: External Function (EF) Codes 4

Table 2-2: Messages to EC 4

Table 2-3: Messages from EC 5

Table 2-4: Test Message 5

Table 2-5: Time and Status Data Message 5

Table 2-6: Select Data Message 6

Table 2-7: Attitude Data Periodic Message 6

Table 2-8: Navigation Data Periodic Message 7

Table 2-9: Keyboard Control Characters 8

Table 2-10: Operator Command Syntax, part 1 9

Table 2-11: Operator Command Syntax, part 2 10

Table 2-12: Data Recording - General Format 13

Table 2-13: Data Recording - List of Events and Event Codes 14

Table 2-14: Data Recording - Event Data 15

Table 3-1: Normal Message Protocol 18

Table 3-2: Conditions for Generating Messages from INS 19

Table 3-3: Operator Commands 20

Table 3-4: List of Alerts 23

Table 5-1: Initial Built-In Tests 28

• Table A-i: INS Simulator Program: Timing Constraints 35

CMUISEI-87-TR-33 v

Inertial Navigation System SimulatorBehavioral Specification

Abstract: The Ada Embedded Systems Testbed Project at the Software Engineering Insti-tute is specifying and developing a representative real-time application. This documentaugments an original set of specifications written by a Navy affiliate. The purpose of thisbehavioral specification is to clarify and augment the original.

1. IntroductionThe Inertial Navigation System (INS) Simulator system [Meyers 87a] consists of the INS computer,the external computer (EC), the INS simulator program [Meyers 87b], the external computer program(Meyers 87c], and an operator interface to each.

This document specifies the INS simulator program in terms of its external interfaces and its dynamicbehavior. The purpose is to clarify and supplement the functional specification [Meyers 87b].

The document contains five chapters:

1. Introduction2. Input/Output Interfaces: specifies the external interfaces of the INS simulator com-

puter in terms of the data structures that are transferred and the layout of the infor-mation presented to the operator (i.e., a static view).

3. External Behavior: describes the externally visible behavior of the INS simulator pro-gram in terms of the responses to specified inputs and the conditions for generatingparticular outputs (i.e., a dynamic view).

4. Internal Behavior: describes those aspects of the behavior of the INS simulator pro-gram that are not directly visible (e.g. motion simulation calculations).

5. Initialization, Control, and Termination: describes the overall process of initializing,controlling, and terminating the INS simulator program.

Two appendices are included:

A. Timing Constraints: contains a summary of timing constraints that were extracted from

the functional specification [Meyers 87b].

B. Communications Link Statecharts: contains a collection of state transition diagrams(statecharts) that define in detail the required behavior of the communications link.

Because it is a requirement to implement the INS simulator program on a variety of computers, someimplementation-dependent details have been left unspecified.

CMU/SEI-87-TR-33

K4

4

I

2 CMU/SEI.87.TR-33

2. Input/Output InterfacesThis chapter specifies the external interfaces of the INS simulator computer in terms of the data

structures that are transferred and the layout of the information presented to the operator. This is astatic view of the external Interfaces; the externally visible, dynamic behavior of the INS simulatorprogram is specified in the next chapter.

Figure 2-1 shows a high-level view of the external Interfaces of the INS simulator computer. Theactual physical interfaces are highly implementation dependent and will not be specified here. Eachof the following sections will describe one of these interfaces: communications link between the twocomputers, interface to the keyboard, interface to the screen, and interface to a disk file.

Console ASCI Cursbe ,_ EF Contrl t ,

Keyboard INS - "

External

Simulator 16DtBt Computer

0 omputer

Console AscW CcsScreen

Figure 2-1: Inertial Navigation System Computer Interfaces

2.1. Communications LinkThe communications link Is used to transfer messages between the INS simulator computer and theexternal computer system.

2.1.1. Logical InterfaceAs shown In Figure 2-1, the logical Interface to or from the external computer consists of a stream of17-bit elements, each element consisting of a 16-bit data word and an associated external function(EF) control bit. If the EF bit is high, the data word is interpreted as an external function code;otherwise it is interpreted as a normal message word.

CMU/SEI-87-TR-33

-4

2.1.2. External Function (EF) CodesThe EF codes are used to control the communications protocol and to delimit messages. The codeidentifiers and their functions are listed in Table 2-1. The actual bit patterns are specified in[NAVSEA 821. Note that not all the EF codes defined in [NAVSEA 82] are used in the INS simulatorapplication.

Code FunctionATTN1 Indicate a time-out condition

ATTN2 Enable communications

ATTN4 Disable communications (sent by EC only)

SOTM Start of test messageSOM Start of message

RTR Ready to receive

NRTR Not ready to receive

EOM End of message

ACK Acknowledge (i.e., received a valid message)

NAK Not-Acknowledge (i.e., received an incomplete or invalid message)

Table 2-1: External Function (EF) Codes

2.1.3. Message Types and FormatsThe full range of message types and formats is defined in [NAVSEA 821. The INS simulator appli-cation uses only some of thesa message types. The message types that may be transmitted to theEC are listed in Table 2-2. The message types that may be received from the EC are listed in Table2-3. The contents, but not the detailed formats, of these messages are depicted in Tables 2-4, 2-5,2-6, 2-7, and 2-8. Each message begins with a 2-word header block which specifies the messagetype and the word count.

Message Type Message Contents

Test Message Contains a fixed pattern to allow checking of communications

Time and Status Data Message Contains fields for the time-of-day and various status codes

Attitude Data Periodic Message Contains various fields of numerical data pertaining to the(simulated) ship motion

Navigation Data Periodic Message Contains fields of numerical data pertaining to the (simulated)ship motion

Table 2-2: Messages to EC

4 CMU/SEI-87-TR-33

SMessae Type Message ContentsTest Message Contains a fixed pattern to allow checking of communications

Select Data Message Contains fields to select/deselect the periodic messages that may besent from the INS

Table 2-3: Messages from EC

Message Field Word Count

Message Header 2 words

Source Identification 1 word

Spare 1 word

Test Word TW1 2 wordsTest Word TWO 2 words

Total 8 words

Table 2-4: Test Message

Message Field Word Count

Message Header 2 words

Status 2 words

GMT 2 words

Test Word TWI 2 words

Test Word TWO 2 words

Total 10 words

Table 2-5: Time and Status Data Message

CMUISEI-87-TR-33 5

Message Field Word Count

Message Header 2 words

Data Selection I wordSpare 1 word

Test Word TWI 2 words

Test Word TWO 2 words

Total 8 words

Table 2-6: Select Data Message

Message Field Word CountMessage Header 2 words

Ownship Heading 1 wordOwnship Pitch 1 wordOwnship Roll 1 wordOwnship Heading Rate 1 word

Ownship Pitch Rate 1 word

Ownship Roll Rate 1 word

GMT 2 wordsEast Component of Ownship Velocity 1 wordNorth Component of Ownship Velocity I wordVertical Component of Ownship Velocity 1 word

Ownship Speed I word

Test Word TWI 2 wordsTest Word TWO 2 words

Total 18 words

Table 2-7: Attitude Data Periodic Message

6 CMU/SEI-87-TR-33

Message Field Word Count

Message Header 2 words

Latitude 2 words

Longitude 2 words

- East Component of Ownship Velocity 1 word

North Component of Ownship Velocity 1 word

East Component of Ocean Current 1 word

North Component of Ocean Current 1 word

Ownship Speed 1 word

EM Log Calibration Constant I word

Ownship Heading 1 word

Ownship Pitch 1 word

Ownship Roll 1 word

Radial Error Estimate I word

Time of Gyro Reset 2 words

GMT 2 words

SOM GMT 2 words

Integral of Velocity North 2 words

Integral of Velocity East 2 wordsTest Word TWI 2 words

Test Word TWO 2 words

* Total 30 words

Table 2-8: Navigation Data Periodic Message

CMU/SEI-87-TR-33 7

2.2. Console KeyboardThe console keyboard is used to allow the operator to type in various commands.

2.2.1. Logical InterfaceAs shown In Figure 2-1, the logical interface to the console keyboard consists of a stream of ASCIIcharacters.

The following characters are accepted from the keyboard:

a .. z, A .. Z, 0 .. 9, m, +, -,., horizontal tab, space,backspace, delete, escape, carriage return

All other characters are ignored.

2.2.2. Command SyntaxThe functions of the control characters are shown in Table 2-9.

Character Function

ESC A special signal to the alerts processing function (see Section 3.3.2)HT Equivalent to a space

BS Used to delete the previous character

DEL Used to delete the command string

CR Signals the end of a command string

Table 2-9: Keyboard Control Characters

The non-control characters (including the space character) are used to construct operator commandsas specified by the syntax equations in Tables 2-10 and 2-11 on the following page.

8 CMU/SEI-87-TR-33

m mSET <parameter-nam> - <parameter-value>

SHOW (<parameter-name> I *}

FAULT <variable-name> - <fault-value>

TURN TO 4PORT I STARBOARD) AT <turn-rate> UNTIL COURSE <new-course>

(INCREASE I DECREASE) SPEED TO <speed-value> IN <time-period>

RESET GYRO

USE FILE <file-name>

(ENABLE I DISABLE) DIX

SELECT (SEASTATE I SCENARIO) <n>

BEGIN

PAUSE

STOP

SCLEAR

Notes:

m 1. cparameter-name> is any input parameter to the motion simulation and <parameter-value> is any legal value for the parameter.

2. <variable-name> is any data variable in an output message to the EC and <fault-value>is any value which can occupy the designated storage allotment for that variable in theoutput message.

3. <speed-vaue>/<time-perod> must be less than 800 knots per hour.4. <parameter-name> and range of <parameter-value> must be verified after issuing the

SET command (actual value of parameter is not changed until ENTER command isIssued).

5. All numeric values are expressed In fixed point notation which accepts signed and un-signed integers and real numbers.

6. The note after Table 3-3 distinguishes between commands that are specified in [Meyers87b] and those that have been added by the designers.

Table 2-10: Operator Command Syntax, part I

CMU/SEI-87-TR-33 9

<paramater-name> UNITS MIN* MAX*

HEAVEAMP ftotREAVE_FREQ radians/secHEAVE_PHASE radians 0 360LAC A feet -250 250ZAC S feet -25 25LACC feet -25 25LATITUDE degrees -90 90LIST degrees -2 2LONGITUDE degrees -180 180OCEAN E knotsOCEAN N knotsPITCHAMP degreesPITCH_7RZQ radians/secPITCH PHASE radians 0 360ROLL AMP degreesROLL_FREQ radians/secROLL_PHASE radians 0 2*PiSHIPCOURSE degrees 0 360SHIPSPEED knots 0 40SURGE AmP feetSURGEFREQ radians/secSURGE PHASE radians 0 2*PiSWAY_AMP feetSWAYFREQ radians/sacSWAY PHASE radians 0 2*PiTRIM degrees -2 2YAW AMP feetYAWFREQ radians/secYAW PHASE radians 0 2*Pi

<turn-rate> degrees/sec 0 2<new-course> degrees 0 360<speed-value> knots 0 40<time-period> minutes 0 120<file-name> alphanumeric<n> integer

Table 2-11: Operator Command Syntax, part 2

*Blank spaces indicate that minimums and maximums are to be determined.

10 CMUISEI-87-TR-33

2.3. Console ScreenThe console screen is used to display some system status indicators and numerical quantities per-taining to the simulated motion of the ship.

2.3.1. LogIcal InterfaceAs shown in Figure 2-1, the logical interface to the console screen consists of a stream of ASCIIcharacters. The mnsole screen Is assumed to display at least 24 lines of 80 characters. Thesequences of control characters required to position the cursor are highly implementation dependentand are not described here.

2.3.2. Screen LayoutThe screen is divided into four windows as shown in Figure 2-2. The detailed layout of the the screenis shown in Figure 2-3. Note that the command window, alert window, and the system status windoware allocated two lines, but they actually consist of one line of information and a blank line for windowseparation.

Periodic Display Window 18

Command Window 2

Alert Window 2

System Status Window 2

Figure 2-2: Screen Windows

CMU(SEI-87-TR-33 11

Lat XX_ W GLIT: xx xx xxLong: XXX xX XX E/W TGR: xxxxxx

Course: mom Dog Speed: xx knots

Heading: motxx Dog "Roil: OLXX Dog Rat: ; xox.xx Dog/SecPitch: XX.XX Dog Rate: 4; xxx.xx Deg/SecYaw: xx.xx Dog Rate: * xxxxx Dog/Sec

Surge: ;xx.xx t Sway: ;XX.M t Heave: jixx.xx FtLIst: ; xxx Dog Trim: xxxx DogOman(East): xx.xx knots Ocean (North): xxxx knots

Vol East: xx.xx knots Cumulative: xxxxxxx PtVol North: xxaxx knots Cumulative: xxxxxxx FtVol Vert: xxim knots

EC Communications UP Xxoxx xx

DX: OFF EC Status: UP

Figure 2-3: Detailed Screen Layout

2.4. Disk File

The disk file is used by the data extraction function to record various data items.

2.4.1. Logical InterfaceThe logical interface to the disk file consists of a stream of 8-bit bytes, grouped into blocks.

The codes used to control the interaction with the disk file are highly implementation dependent and

are not described here.

2.4.2. Recording FormatThe general format of a block of recorded data is shown in Table 2-12. Identifying codes are ex-pressed as short mnemonics, and numerical values are expressed in HEXASCII notation. Thus,each block consists of a sequence of printable ASCII characters, terminated by a CR/ILF combination.

12 CMU/SEI-87-TR-33

Field Name Field Description

event type two-character code(2 bytes)

timestamp number of 2.56 msec ticks since program start(8 bytes)

data character codes or numerical values as appropriate(number of bytes varies with event type)

checksum modulo 256 checksum(2 bytes)

terminator ASCII.CR and ASCII.LF characters(2 bytes)

Table 2-12: Data Recording - General Format

The codes for the various event types are shown in Table 2-13.

The timestamp range of 16#00000000# .. 16#FFFFFFFF# ticks is sufficient for several hundred days.

The data recorded for each event type, in addition to the timestamp, are shown in Table 2-14.

*The checksum is the modulo 256 sum of all the preceding bytes in the block

(i.e., a number in the range 0..255 decimal, or 16##00#..16##FF#).

I

CMU/SEI-87-TR-33 13

- - - - - - - - - -

Event Code Event Description

IP Initialization of sea-state and scenario parameters

CP Operator command to change a parameter(note: the timestamp is that of the ENTER command)

IF Operator command to inject a faultIR Initiation of runtime BIT processing

IT Initiation of each runtime test

CT Completion of each runtime test

CC Change in state of communications with external computerIA Issue of an alert to the operator

RA Removal of an alert from the alert list

BS Beginning of session

ES End of session

Table 2-13: Data Recording - List of Events and Event Codes

1

j

14 CMU/SEI-87-TR-33

-I

Event Code Data

IP sea-state number selected (1 byte)scenario number selected (1 byte)

CP (1) parameter id (4-character code) -- details TBD (4 bytes)(2) new value (in operator input format) (8 bytes)

M IF (1) parameter id (4 character code) -- details TBD (4 bytes)(2) fault value (in operator input format) (8 bytes)

IR -- no data--

IT -- no data--

CT -- no data--

CC new communications state (4 character code)

DOWN down (i.e., disabled or attempting to enable)

UP up (i.e., fully enabled)

IA alert id (4-character code) -- details TBD (4 bytes)

RA alert id (4-character code) -- details TBD (4 bytes)

BS date and time (10 bytes for YYMMDDHHMM)

ES date and time (10 bytes for YYMMDDHHMM)

Table 2-14: Data Recording - Event Data

CMU/SEI-87-TR-33 15

16 CMU/SEB.87-TR-33

3. External Behaviorm This chapter describes the externally visible behavior of the INS simulator program, i.e., the re-

sponses to specified inputs and the conditions for generating particular outputs. The interfaces ofconcern are:

* interface with the external computer (communications link)* Interface with the operator (keyboard and screen)

- e interface to an external medium for data extraction (disk file interface)

3.1. Communications LinkAs stated In [Meyers 87b], the communications link between the INS simulator computer and theexternal computer system must conform to the protocol specified in [NAVSEA 82]. The purpose ofthis section (and Appendix B) is to give a condensed version of the detailed information in[NAVSEA 82] and in [Meyers 87b].

Communications with the external computer can be in one of three states: disabled, enabling, orenabled. In each of these states, the INS sends and receives data while bound to a specific protocol(i.e., sequence of external function codes and data words). The INS can be viewed as a server to theexternal computer; that is, the external computer determines INS behavior and can cause pre-emption of INS message activity. The external computer initiates the enabling and disabling of theINS communications link, directs that certain data be sent or not sent, and periodically requests thatthe INS respond to test messages.

Sending a successful message consists of an exchange that includes a block of data words,preceded and followed by a pair of EF codes, as detailed in Table 3-1.

I •Figure 3-1 depicts the overall behavior of the communications link in the ideal case with no trans-mission errors. The communications link is initially in the disabled state. The external computerinitiates the communications protocol with an ATTN2 EF; the INS responds with an ATTN2; and thesystem enters the enabling state. In the enabling state, the EC sends a test message, and the INSresponds with a test message. After the successful exchange of these messages, the system entersthe enabled state. In the enabled state, the INS computer accepts and sends messages as dictatedby the functional requirements specified in [Meyers 87b) and summarized In Table 3-2. Note that inthe case of a conflict, sending an attitude periodic data message takes precedence over sending anavigation periodic data message.

The idealized scenario of Figure 3-1 can be disrupted by a variety of events (e.g., intended recipientnot ready, erroneous message, time-out waiting for a response). The full behavior of the communi-cations link Is defined in Appendix B.

CMU/SEI-87-TR-33 17

1. The initiator of a message sends a start-of-message (SOM)or start-of-test-message (SOTM) signal, as appropriate.

2. The recipient, if ready, responds with a ready-to-receive (RTR) signal.3. The initiator sends the data block, followed by an end-of-message (EOM) signal.

4. If no errors are detected, the recipient responds with an acknowledge (ACK).

Table 3-1: Normal Message Protocol

INS ATTN 2 EC TIME

Comms ATTN 2_ _._

DisabledS SOTM

REC sends

EnaTlng Test MessageEnablingto INSComms 4, EOM t N

ACK

SOTM oil " INS sendsACK/ Test Message

- to EC

Comms RTRExam

Enabled INS andsDNavigation

PeriodicEOM - Message

,, ACK

Figure 3-1: Communications Protocol: Summary

18 CMU/SEI-87-TR-33

A

Messaae Type Conditions

Time and Status Data Message Sent immediately upon entry to the enabled state,and in response to a select data message from the EC

Test Message Sent in response to a test message from the EC

Attitude Periodic Message Sent once every 61.44 seconds, if enabled- (bya previous select data message from the EC)

Navigation Periodic Message Sent once every 983.04 seconds, i enabled

Table 3-2: Conditions for Generating Messages from INS

CMU/SEI-87-TR-33 19

3.2. Console KeyboardThe effect of each of the operator commands is described in Table 3-3.

Command Effect

SELECT SEASTATE Use the specified set of amplitude and frequency parameters for the mo-tion simulation.

SELECT SCENARIO Use the specified set of ship parameters for the motion simulation. -

BEGIN Start (or restart) the motion simulation.

SET PARAMETER Save the new value of the specified parameter, to be used upon the nextENTER command.

SHOW PARAMETER Display the value of the specified simulation parameter.

SHOW Display the values of all simulation parameters, usurping the periodicdisplay window of the screen and disabling the normal periodic update ofthis window.

CLEAR Erase the periodic display window of the screen, rewrite the fixedlegends, and re-enable the normal periodic update of this window.

FAULT Save the specified fault value of the specified variable; upon the nextENTER command, use that value to inject a fault into the next outputdata message, in place of its true value.

ENTER Actually make the changes to the simulation parameters as specified inmost recently issued SET PARAMETER and FAULT commands (i.e., is-sued since the last ENTER command).

change COURSE Use the new course parameters for the motion simulation.

change SPEED TO Use the new speed parameters for the motion simulation.RESET GYRO Set the Time of Gyro Reset to the current system time.

USE FILE Open the specified file for use as the data extraction file.

ENABLE DEX Enable the data extraction function (provided that a file has beenspecified).

DISABLE DEX Disable the data extraction function.

PAUSE Temporarily freeze the simulation (it may be restarted with the BEGINcommand).

STOP Terminate the simulation program.

Table 3-3: Operator Commands

OriQin of Commands:

The following commands are specified explicitly In [Meyers 87b]: SET PARAMETER, SHOWPARAMETER, change COURSE, change SPEED,

ENTER, FAULT, RESET GYRO

The following commands are specified implicitly in [Meyers 87b]: SELECT SEASTATE, SE-LECT SCENARIO, USE FILE, ENABLE DEX, DISABLE DEX

20 CMU/SEI-87-TR-33

The following commands have been invented to provide needed functionality:BEGIN, PAUSE, STOP, SHOW , CLEAR

3.3. Console ScreenThe behavior of each window is defined separately.

-3.3.1. Command WindowThe command line is Initially blank. As the operator types a command, the individual (printable)characters are echoed in the command line. If the operator uses the backspace (BS) and delete(DEL) characters to edit the command string, changes are reflected in the command line. The oper-ator indicates the end of a command by typing a carriage-return (CR) character. This CR is notechoed directly; instead a "I" character is appended when a command has been executed success-fully, or a "?" character is appended when a command has been found to be invalid.

When a SHOW PARAMETER command is entered, the value of the specified parameter is displayedin the remainder of the command line, in the following format:

SHOW PARAMETER <parameter-name> , <parameter-value> <unit-of-measure> !

where <parameter-name> is as specified in Section 2.2.2,<parameter-value> is in the appropriate numeric form, and<unit-of-measure> is as specified in Section 2.2.2.

* A command remains on display until the first character of the next command is typed. Thus, the

command line displays the following:

1. a blank line2. an incomplete command string

3. an apparently complete command that has not yet been terminated with a CR4. a complete command with an indication of whether it has been accepted

5. a SHOW PARAMETER command, followed by the value of the specified parameter

3.3.2. Alert WindowThe alert line is blank at program initiation. Immediately after the completion of the Initial Built-InTest, the alert line will display an indication of either a successful BIT or a test failure.

When any of the events listed in Table 3-4 occurs, an alert will be issued (see [Meyers 87b)). If thereis no alert currently displayed, the new alert is displayed; otherwise, the new alert is added to a list ofpending (capacity of the list is 50 alerts). Additionally, the audible alarm will sound for 2 secondswhen an alert is issued.

When the operator types an escape (ESC) character, the currently displayed alert (if any) is erased,

and the highest priority pending alert (if any) is removed from the list of pending alerts and displayed.Thus, the alert line is either blank, or it contains the following:

* the alert text string* the time at which the alert was issued (i.e., detected)

CMU/SEI.87-TR-33 21

*the numbter of pending alerts (blank I zero)

22 CMU/SEI-87-TR-33

.3 RUNTIME BIT FAILUREINITIAL BIT REGISTER TEST FAILUREINITIAL BIT ADDRESS READ/WRITE FAILUREINITIAL BIT ARITHMETIC TEST FAILUREINITIAL BIT MEMORY CHECKSUM FAILURE

II INITIAL BIT TEST SUCCESSFULFAULT CHANGES COMPLETED

INVALID MESSAGE TYPE IN MESSAGE

INVALID NUMBER OF WORDS IN MESSAGEINVALID TEST PATTERN RECEIVED

EC COMMUNICATIONS UPEC COMMUNICATIONS DOWNEC COMMUNICATIONS ENABLEDSELECT MESSAGE RECEIVED FROM ECINVALID COURSE CHANGE

INVALID SPEED CHANGEINVALID TURN COMMANDINVALID DX FILE SPECIFIED

UNABLE TO OPEN DX FILE3 DX FILE WRITE ERROR

PARAMETER INITIALIZATION COMPLETE

PARAMETER CHANGES COMPLETEDINVALID SET PARAMETER REQUESTINVALID SHOW PARAMETER REQUEST

I INVALID FAULT REQUESTINVALID DATA EXTRACT REQUESTINVALID ENTER COMMANDINVALID ENTRY

NOTES:

1. Alerts are listed In descending order of priority.

2. This is the minimal list of alerts specified in [Meyers 87b]. Additionalalerts will be defined as required to indicate other erroneous conditions(e.g. time-out detected in the communications link, scheduling deadlinemissed, buffer overflow).

Table 3-4: List of Alerts

CMU/SEI-87-TR-33 23

3.3.3. System Status WindowThe system status window displays the current status of the communications link (down/up) and thedata extraction function (off/on), as shown in Figure 2-3.

The fixed legends are written once, at program initiation, together with the initial values of the statusindicators.

When the status of the communications link or the data extraction function changes, the appropriateindicator should change within 1000 milliseconds.

3.3.4. Periodic Display WindowThe periodic display window displays various numerical quantities relating to the simulated ship mo-tion, in the format shown in Figure 2-3.

The fixed legends are written once, at program Initiation, together with blanks in the numerical fields.

The numerical fields are updated at least once every 1000 milliseconds while the simulation is active(see Chapter 5).

3.4. Disk File Interface (Data Extraction)The data extraction function is controlled as described in Table 3-3 by the commands:

USE FILE <name>

ENABLE DEX

DISABLE DEX

The data extraction function is initially disabled. When the operator types a USE FILE command, theappropriate disk file is opened (if possible).

When any of the events listed in Table 2-13 occurs and data extraction is enabled, a data extractionrecord will be written to the disk file. The format of each type of record is specified in Section 2.4.

When the operator terminates the INS simulation program with a STOP command, the disk file isclosed.

24 CMU/SEI-87-TR-33

4. Internal BehaviorThis chapter describes the aspects of INS simulator program behavior that are internal to the pro-

gram, including the motion calculations and the Runtime Built-In Test.

4.1. Motion Calculations

When the motion simulation is active (see Chapter 5), three sets of ship motion calculations are

performed at specified frequencies.

4.1.1. Update Ship AttitudeEvery 2.56 milliseconds, do the following, as specified in Appendices 2, 3, and 4 of [Meyers 87b]:

" Calculate (simulated) roll and roll rate." Calculate (simulated) pitch and pitch rate.

" Calculate (simulated) yaw, heading, and heading rate.

4.1.2. Update Ship VelocityEvery 40.96 milliseconds, do the following, as specified in Appendices 5, 6, 7 and 8 of [Meyers 87b):

" Update the commanded course if a course change is underway.

" Update the commanded speed if a speed change is underway.

" Calculate surge, heave, and sway.• Calculate velocity of the ship's center of gravity (CG) with respect to the water." Calculate true velocity of the ship's center of gravity.

" Calculate motion at the position of the INS within the ship (attitude and velocity).

" Update the uumulative velocity integrals.

4.1.3. Update Ship PositionEvery 1300 milliseconds, do the following, as specified in Appendix 9 of [Meyers 87b]:

e Update the latitude and longitude of the ship.

4.2. Runtime Built-In Test

The Runtime BIT function will be performed every 1000 milliseconds as specified in [Meyers 87b].

The test will determine if the contents of the output message buffers lie within the acceptable bounds

specified in [NAVSEA 82].

CMU/SEI-87-TR-33 25

I

26 CMU/SEI-87-TR-33

5. Initialization, Control, and Terminationi U This chapter describes the process of initializing, controlling, and terminating the INS simulator pro-

gram.

A typical timeline from program initiation to program termination is shown in Figure 5-1. Note that thistimeline represents the ideal case.I.

TIME

Ada ElIx"O~aonWnPrcmedure starts

hnlbI BIT

Device Intltlization

Default Paramear Initialization

Other Initiatizaton

Ready to accept commands-Accept operator commands

BEGIN command-

- Simulate &. Accept opeaor commands

i PAUSE oommand-Accept operator commands

BEGIN ommand

- Simulate &* Accept operalor commands

STOP oommand

Figure 5-1: Program Timeline

m7

CMU/SEI-87-TR-33 27

5.1. Program Preparation and Initiation

The process of program preparation and initiation is highly dependent on the host and target systemsand will not be specified here.

5.2. Initial Built-In Tests

[Meyers 8Tb specifies performance of the following Initial Built-In Tests (see Table 5-1) immediately -upon program initiation. However, this poses special problems in Ada because the runtime systemperforms various package elaborations before transferring control to the main program.

Register checks

Address read/write test

Memory checksum

Arithmetic capability test

Table 5-1: Initial Built-In Tests

Since the first three tests are highly dependent on the implementation system, it may not be feasibleto implement them exactly as specified in [Meyers 87b]. However, the arithmetic capability testshould be implementable using Ada code only.

5.2.1. Arithmetic Capability Test 1

This test will check

* the algebraic Identity: sqrt(x) sqrt(x) - xfor 10 random numbers in the range IOe-10..1Oe10

" the trigonometric identity: sln2x + cos 2x _ 1for 10 random angles in the range 0..2*Pi

The actual random numbers and angles are still to be determined, as are the tolerances. It shouldalso be possible to express the tolerances for these checks in an implementation-independent man-ner using Ada floating point attributes.

28 CMU/SEI-87-TR-33

5.3. Program InitializationAfter the successful completion of the Initial BIT function, the following program initialization functionsare performed in the order given.

5.3.1. Device InitializationSome Implementation-specific device initializations will need to be performed, but they are not de-scribed here. Certain implementation-independent initializations will also be performed, as describedIn Chapter 3.

5.3.2. Motion Simulator Parameter InitializationA sea-states table contains seven sets of amplitude and frequency parameters to simulate ship'smotion in sea-states I through 7. A scenarios table contains nine sets of other ship parameters thatare required to fully define a simulation. The parameters will be initially set to sea-state 3 andscenario 1.

5.3.3. Other InitializationThe Time of Gyro Reset is set to current wall-clock time.The state of the communications link is set to DOWN.The state of the data extraction function is set to OFF.

5.4. Program ControlThe program is now ready to accept operator commands from the keyboard and messages from theexternal computer system. (Any commands or messages received before this point are ignored).The program remains ready to accept operator commands and EC messages until it is terminated.Wholesale re-initialization of the current parameters may be accomplished by these operator com-mands:

SELECT SEA-STATE <n>

SELECT SCENARIO <n>

Any of the operator commands listed in Table 3-3 may be now be issued.

The simulation starts when the operator enters a BEGIN command.The simulation is temporarily frozen if the operator enters a PAUSE command; it can be restarted byanother BEGIN. The purpose of the PAUSE/BEGIN feature is to assist in debugging and monitoring.)The program continues until terminated by the operator with a STOP command.

CMU/SEI-87-TR-33 29

r.

II

5.5. Program TerminationThe INS simulation program is terminated when the operator enters the STOP command, providedthat the external computer has already disabled communications. If communications are still en-abled, the STOP command is ignored.

3

30 CMU/SEI-87-TR-33

Glossary*AEST Ada Embedded Systems Testbed (Project)

BIT Built-in Test(s)CG center of gravityDX, DEX data extractionEC external computer systemEF external function (code)EM electro-magneticFIFO first-in first-out

-GMT Greenwich mean timeINS Inertial Navigation System

CMU/SEI-87-TR-33 31

32 CMU/SEI.87-TR-33

References

(Harel 86] Harel, D.Statecharts: A Visual Formalism for Complex SystemsScience of Computer Programming, 8, 1987pp. 231-274

[Meyers 87a] Meyers, B. C.Systems Specification Document for an Inertial Navigation System Simulator andExtemal ComputerSoftware Engineering Institute, February 1987To be published.

[Meyers 87b] Meyers, B. C.Functional Performance Specification for an Inertial Navigation System SimulatorSoftware Engineering Institute, February 1987To be published.

(Meyers 87c] Meyers, B. C.Functional Performance Specification for an External Computer to Interface to anInertial Navigation System SimulatorSoftware Engineering Institute, February 1987To be published.

[NAVSEA 82] NAVSEAInterface Design Specification for the Inertial Navigation Set AN/WSN-5 to Exter-nal ComputerNAVSEA T9427-AA-IDS-010/WSN-4, August 1982

CMU/SEI-87-TR-33 33

34 CMU/SEI-87-TR-33

Appendix A: Timing ConstraintsU Time (ma) e (*) Item (**) Reference (***)

2.56 S Timestamp for Data Extraction

2.56 P Update Ship Attitude FPS 4.7P Update Ship Heading FPS 4.9

5.12 T NRTR "sleep" IDS 6.3.2.2.b.1

10.24 T ATTN2 / SOTM Time-Out IDS 6.2.1.c10.24 T SON I (RTR or NRTR) Time-Out IDS 6.3.2.1.a10.24 T RTR / EOM Time-Out IDS 6.3.2.2.b10.24 T EON / (ACK or MAR) Time-Out IDS 6.3.2.1.c10.24 T SOTH / (RTR or NRTR) Time-Out IDS 6.3.2.3.a

40.96 P Update Ship Speed FPS 4.6P Update Ship Displacement FPS 4.8P Update Ship Velocity (& vel integrals) FPS 4.11

61.44 P Send Attitude Periodic Message IDS Table 5-1

983.04 P Send Navigation Periodic Message IDS Table 5-1

1000. P Perform Runtime BIT FPS 4.14

1000. P Update Status Display on Screen FPS 4.3.1 (2)

1300. P Update Ship Position (Lat & Long) IDS p 4-11

KEY

(*) Type of Timing Requirement* P Periodic

S TimestanpT Time-Out

(**) Messaae EF CodesATTN2 InitializationSOTH Start of test messageSON Start of messageEOm End of messageRTR Ready to receiveNRTR Not ready to receiveACK Acknowledge (i.e., valid message received)MAX Not Acknowledge (i.e., invalid message received)

(***) Specification DocumentsIDS Interface Design Specification, AN/WSN-5 to External ComputerFPS Functional and Performance Specification for INS Simulator

Table A-1: INS Simulator Program: Timing Constraints

CMU/SEI-87.TR-33 35

36 CMU/SEI-87-TR-33

Appendix B: Communications Link StatechartsThis appendix contains a set of statecharts [Harel 86] that describes the behavior of the communi-cations link from the perspective of the INS. This behavior is presented textually in Chapter 6 of[NAVSEA 82. The goal here is to formalize and clarify.

Statecharts incorporate extensions to traditional state transition diagrams that allow for the represen-M tation of concurrent states and nested states. The first section below summarizes statechart graph-

ical syntax. The following sections exhibit statecharts with accompanying narrative.

B.a. Summary of Statechart Syntax1. States are represented as boxes. Boxes may be nested, allowing one to view states at

varying levels of abstraction.2. Transitions are represented by arrows emanating from a box. Arrows emanating from

an outer box represent a transition from any box which it encapsulates. Transitions fromseveral sources may converge on a dot, which also has exiting transitions. This pro-vides an economical mechanism for applying additional conditions and actions to alltransitions that converge on the dot.

3. Events cause state transitions to take place. They are denoted as labels of a transi-tion.

4. Actions may be associated with an event. When actions are present, they appearbelow a line in the label, where the triggering event appears above the line. An amper-

3i sand (&) is a separator between multiple actions.

5. Concurrent states are represented as two boxes with a common side that is a dottedline.

6. Initial states entered when entering a set of encapsulated states are indicated by anarrow with a dot at its tail. In the example below, states Al and 81 are the initial statesthat are entered simultaneously, and event e causes a transition to states A2 and 63.

CMU/SEI-87-TR-33 37

p7

A2

7. Conditions are denoted by text in parentheses. State transitions can be triggered by atrue condition.

8. History is shown by an arrow that points to an encircled H; the H indicates that thetransition should be made to the most recently exited state.

9. Expansion is shown by boxes with an asterisk in the upper right corner; these repre-sent states that have internal detail which is presented in a subsequent statechart.

38 CMU/SEI-87-TR-33

i I

B.b. Master Communications Link StatechartThis chart is the highest level statechart of the INS communications link. It shows the three major

states of the communications link: disabled, enabling, and enabled. Receiving an ATTN2 from theexternal computer precipitates several actions and causes transition to the enabling state. Successin the enabling state results in a transition to the enabled state, and failure to enable results in atransition back to disabled. Note that receiving an ATTN2 and AT"N4 will precipitate the indicatedtransition from any substate hidden Inside the indicated states. Also note that the asterisks in theupper right comer of the boxes indicate that subsequent statecharts exist to show the detail that ishidden at the current level.

Comms Unk

receive ATTN2

receive A'n'N2 * EC acknowledges*send A TrN2 & Test Ms2 -0, C M

comms start 1024 ms imer.' lEnabling Com

Disabled ealnunucsflcomms ..,receive Al~rN2 Enabled

receive ATrN4

I3

U

CMU/SEI-87-TR-33 39

B.c. Enabling Communications StatechartThis statechart is an expansion of the enabling communications state of the higher level. The ena-bling protocol consists of receiving and sending a test message. Note the use of partial boxes toindicate a state at a higher level.

Enabling Comms

receiving (valid test msg) sending EC acknowledges test msg Comms"enabling" - "enabling" n-betestrnsg .test msg - -n -e

%,not raceve VM0 _,,OO 4ynt senf

commr

DiEnabled

I I

40 CMU/SEI-87-TR-33

-

BAd Receiving Enabling Test Message Statechart3 This statechart exhibits the details of receiving a test message during the enabling process. Note that

time-outs result in a transition back to the disabled state. Also, receiving an NAK when validating thetest message results in a transition to the disabled state. Out of sequence or nonexistent EFs areignored as indicated by the transition to the encircled H, with ATTN2 being the exception.

Receiving Enabling Test Msg

reev TIreceive ATTNI receive ATTNI(ignore) watoeao6e

receive SOTMsend RTR & rcieEMejlg

A w it n re t rt1 .2TsMr e Receiving sto tlf Validating (If valid) enabing "Awatin Mssar 10.24 mg timer Aci estg

10.24 me since 10.24 ms sinceArrN2 was sent FUR was sent (dInvalidsend ATrNt & send ATFN1 & send NAK &

wortopertor ign peraor aert operator

Commli;or nonexistent EF91

\Disabled'

except ATTN2: se Conms Link statechurts

CMU/SE1-87-TR-33 41

B... Sending Enabling Test Message StatechartThis statechart exhibits the details of sending a test message during the enabling process. Note thatthe starting transition in this statechart is labeled with an event that also appears on a higher levelstatechart (see Section B.c). The actions associated with this event are considered unnecessarydetail at the higher level and thus are represented at this level. Also note the use of concurrent statesto remember the numbter of attempts that have been made to send the message.

Sending Enabling Test Msg2

rriecie valid tesetv NAK@top timer & ~

sa10.24 mas ice

smwasetreceiv ATYralweAiseit n d seTnd u I w iig so fo n

SOIMer Counte (I ONE) Comm

recese SNd Icemn recin NW) iabestop fnle&rt oprato

I etr 1024 ms sinc

0-24 sequsinceor no e t n Eent

A4141

Inc:

B.f. Communications Enabled StatechartThe statechart on the following page presents the details of the communications enabled state as aset of three concurrent states. Upon entering the communications enabled state, the INS sends the

time and status message; the sending of the two periodic messages is in a disabled state.

The state, sending message to EC, has four substates, one for each type of message. The detailed

statechart for sending each of these messages Is common and is exhibited in a later statechart

labeled Sending message to EC (see Section B.h). Note that if the INS is in the middle of sending a

message and either an SOM or SOTM arrive, the original message is aborted and the protocol for

receiving a message is enforced. Also notice the interactions between several concurrent states. For

example, when the select data (SD) message arrives and requests that the INS send periodic naviga-

tion data, the associated action Is enable nav. This action is also an event which triggers the transi-

tion to the state of waiting to be dispatched.

CMUISEI-87-TR-33 43

Comirn Enabled

If~~~~reev Sot evnsanha rirt

PerioicoaydicEbe

963d manpre n ntI

TeOnetoo"Na MegtMe

Periodic Naf Mg Enabled

613 me expired and Idle98 nexle

enablenov 61 m expired and not Idle

Navigtion isabe nay-aot operator

Periodi Att Ms Enable61~~ ~ ~ Queue exieadIl

Ic ddequeuana-

44 CMU/SEI-87-TR-33

B.g. Receiving Message from External Computer StatechartU This statechart represents the details for receiving any message when communications is in the

enabled state. It is similar to the statechart that shows receiving a test message during enabling(refer to the statechart in Section B.d).

Receiving Msg from EC

receive ATTI receive ATTNI

receive SOM or SOTIVsend RTR &

star 1024 rs trnerr I OM(11 valid)R~ecevingValidating send ACK

o04matmr nexie t invakilo

r - P

except SCM, SOrM, ATTN2 and ATfl14; on higher level statecharts

2 this event Is also shown on previous statechart

CMU/SEI-87-TR-33 45

B.h. Sending Message to External Computer StatechartThis statechart represents the details for sending any message when communications is in the en-abled state. It is very similar to the statechart that shows sending a test message during enabling(refer to the statechart in Section B.e).

Sendng Msg to EC

Ssen meg or mug queuiedsend SOil or SOTM &stort 10.24 me timer

Sending

receive RTRAwaiting stnd .m tier Awaiting

restart~eciv 102 m CmrK C

stop timer

receve NRTR [rcive NAA&stop tImer & stop timer

sleep 5.12 ms

10.24 me ecve ATTN Idl

terexpired---

SOM Counter nTO

IOne rsort 10.24 ms timer

out of seqiuenceor non-existent EFs

I except Soil or SOTM and ATTN2 & ATrN4: ane higher level statecharts

2te Comm* Enabled stutechart alsam rersentts this event

46 CMU/SEI-87-TR-33

UNLIMITED, | Nri.Aq TE T rn

99CURITY CLASSIFICATION OF THIS PAGE

REPORT DOCUMENTATION PAGE,. REPORT SECURITY CLASSIFICATION lb. RESTRICTIVE MARKINGS

UNCLASSIFIED NONE2a. SECURITY CLASSIFICATION AUTHORITY 3. DISTRIBUTION/AVAILABILITY OF REPORT

N/A APPROVED FOR PUBLIC RELEASE

2b. DECLASSIFICATION/DOWNGRAOING SCHEDULE DISTRIBUTION UNLIMITEDN/A

4, PERFORMING ORGANIZATION REPORT NUMBER(S) 6. MONITORING ORGANIZATION REPORT NUMBER(S)

-CMU/SEI-87-TR-33 ESD-TR-87-196

6G. NAME OF PERFORMING ORGANIZATION b. OFFICE SYMBOL 7a. NAME OF MONITORING ORGANIZATION(if applicabiel

SOFTWARE ENGINEERING INSTITUTE SEI SEI JOINT PROGRAM OFFICE

6c. ADDRESS (City. State ad ZIP Code) 7b. ADDRESS (City, State and ZIP Code)

CARNEGIE MELLON UNIVERSITY ESD/XRSIPITTSBURGH, PA 15213 HANSCOM AIR FORCE BASE, MA 01731

do, NAME OF FUNDING/SPONSORING BSb. OFFICE SYMBOL 9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER

ORGANIZATION (I[ applicable)

SEI JOINT PROGRAM OFFICE SEI JPO F1962885C0003

ft. ADDRESS (City. State and ZIP Code) 10. SOURCE OF FUNDING NOS.

CARNEGIE MELLON UNIVERSITY PROGRAM PROJECT TASK WORK UNIT_ _ _ _ _ _ _ _ _ _ _. TO N ,NO.

SOFTWARE ENGINEERING INSTITUTE JPO ELEMENT NO. NO. NO.

PTTTURIRG1H. PA 15213 N/A N/A N/A11. TITLE (include Security Clauificationl

INERTIAL NAVIGATION SYSTEM SIMULATOR: BEHAVI RAL SPECIFICATION

12. PERSONAL AUTHOR(S)

Stefan F. Landherr, Mark H. Klein13a. TYPE OF REPORT 13b. TIME COVERED 14. DATE OF REPORT (Yr.. Mo.. Day) 15. PAGE COUNT

FINAL I FROM _ TO October 1987 45I. SUPPLEMENTARY NOTATION

17. / COSATI CODES 16. SUBJECT TERMS (Continue on reverse if nece.sary and identify by block number)

FIELD GROUP SUB GR. Ada runtimeembedded system Ada artifact

Rreal-time system

19. A TRACT (Continue on reverse if necessary and identify by block number)

The Ada Embedded Systems Testbed Project at the Software Engineering Institute isspecifying and developing a representative real-time application. This documentaugments an original set of specifications written by a Navy affiliate. Thepurpose of this behavioral specification is to clarify and augment the original.

//

20. DISTRIBUTION/AVAILABILITY OF ABSTRACT 21. ABSTRACT SECURITY CLASSIFICATION

UNCLASSIFIED/UNLIMITED rX SAME AS RPT. [ OTIC USERS U UNCLASSIFIED, UNLIMITED

22s. NAME OF RESPONSIBLE INDIVIDUAL 22b TELEPHONE NUMBER 22c OFFICE SYMBOL(include A4 prDod.

KARL SHINGLER (412) 268-7630 SEl JPO

D FORM 1473 R3 APR EDITION OF I JAN 73 IS OBSOLETE. UNLIMITED, UNCLASSIFIED