dok.-nr/doc. no.: col–ribre–std–0009...document change record issue/rev. date affected...

Dok.-Nr/ Doc. No.: COL–RIBRE–STD–0009Ausgabe /Issue: 2Überarbtg./ Rev.: B

Datum/Date : 23.2.1996

Datum/Date: 31.10.2001

Daimler–Benz Aerospace AG, D–28199 Bremen – All Rights reserved – Copyright per DIN 34

Dokument Typ: STANDARDDocument Type:

Titel: High Level Command Language (HLCL) Reference ManualTitle:

Lieferbedingungs–Nr.: Klassifikations Nr.:

DRL/DRD No.: Classification No.:

Produktgruppe: Konfigurationsteil–Nr.:

Product Group: Configuration Item No.:

Schlagwörter: HLCL Porduktklassifizierungs–Nr.:

Headings: High Level Command Language Classifying Product Code:

Interactive Commanding

Freigabe Ordnungs–Nr.:

Release Orde No.:

Vorherige Dok.–Nr.:

Previous Doc. No.:

Bearbeitet: F. Kruse Org. Einh.: IO 62 Unternehmen: Astrium BremenPrepared by: Orgin. Unit: Company:

Geprüft: W. Bölke Org. Einh.: IO 42 Unternehmen: Astrium BremenAgreed by: Orgin. Unit: Company:

Genehmigt: P. Davies Org. Einh.: IO 42 Unternehmen: Astrium BremenApproved by: Orgin. Unit: Company:

Genehmigt: H.–J. Pospieszczyk Org. Einh.: IO 41 Unternehmen: Astrium BremenApproved by: Orgin. Unit: Company:

3.745

1211382

STD 1214573

DOCUMENT CHANGE RECORD

ISSUE/REV. DATE Affected Paragraph/Page DESCRIPTION OF CHANGE

Dok.-Nr/ Doc. No.: COL–RIBRE–STD–0009Ausgabe /Issue: 2Überarbtg./ Rev.: BSeite/Page: I

Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of IV


0 / – 15.5.1991 all initial issue1 / – 26.3.1992 all Rids and comments from HLCL review (12.12.91)

incorporated1 / A 17.02.1993 all COL–ERNO–DDR–0174 & –0175

4.1 HCI–02–02–2074.3 HCI–02–02–2085.1 HCI–02–02–2095.5 HCI–02–02–210all HCI–02–02–211all HCI–02–02–2125.11.2.6 HCI–02–02–214

HCI–02–02–2163 HCI–02–02–6113 HCI–02–02–612 picture updated

HCI–02–02–613HCI–02–02–614HCI–02–02–615HCI–02–02–616HCI–02–02–617HCI–02–02–618HCI–02–02–619HCI–02–02–620HCI–02–02–621HCI–02–02–622HLCL–01–001HLCL–01–002HLCL–01–003HLCL–01–004

5.6.91 all M. Danne – Inputs from VICOS team15.7.91 all S. Lütt – Inputs from the CSS team1.9.91 all COL–MBER–ZU1–TN–0011

2/– 23.2.1996 all COL–RIBRE–DDR–0563changes required by COL–RIBRE–DDR–0587which has not been formally approved but the con-tents are agreed.

2/A 13.03.98 2.1 Ref. to applicable document updated.4.2.1, page 6 Delete ”Parameter lists must be enclosed in par-

entheses.”

DOCUMENT CHANGE RECORD

ISSUE/REV. DATE Affected Paragraph/Page DESCRIPTION OF CHANGE

Dok.-Nr/ Doc. No.: COL–RIBRE–STD–0009Ausgabe /Issue: 2Überarbtg./ Rev.: BSeite/Page: II

Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of IV


4.17, page 13 Change ”LIBRARIES” to ”IMPORTS” in typeOBJECTS.

2/B 31.10.2001 2.1 COL–RIBRE–SPR–7020:Ref. to applicable document updated.

4.8 COL–RIBRE–SPR–7020:New standard function IMPORTED

4.2.1 COL–RIBRE–SPR–10603:Local declaration part in command sequences

4.16, 4.19.3 Adaptations to UCL RM 4/A

Dok.-Nr/ Doc. No.: COL–RIBRE–STD–0009Ausgabe /Issue: 2

Überarbtg./ Rev.: BSeite/Page: III

Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of IV


Table of Contents

1 INTRODUCTION 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1 Identification and Scope 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Purpose 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 APPLICABLE AND REFERENCE DOCUMENTS 2. . . . . . . . . . . . . . . . . . . . . . .

2.1 Applicable Documents 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Reference Documents 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 LANGUAGE CONCEPTS 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 HLCL and UCL 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 General principles 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Usage 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 LANGUAGE DEFINITION 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Sessions 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Debug mode 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Command logging 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Command Sequences 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Command sequence syntax 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Echo mode 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Error handling in command sequences 7. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Single step mode 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Command lines 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Command and function classes 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.5 Import 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.6 Declarations 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.7 Assignment 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.8 Standard procedures & functions 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.9 Simple commands 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.10 Return command 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.11 Structured commands 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.12 Expressions 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.1 Path names 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.2 Type conversions 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12.2 Conversion to string 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.13 Type overloading 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.14 Units of measure 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.15 Abbreviations 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.16 Help facility 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dok.-Nr/ Doc. No.: COL–RIBRE–STD–0009Ausgabe /Issue: 2

Überarbtg./ Rev.: BSeite/Page: IV

Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of IV


4.17 Predefined types 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.18 Predefined variables 14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.19 Predefined commands 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19.1 Display commands 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19.2 Command sequence related commands 16. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19.3 Input/output commands 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19.4 Command logging commands 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.20 Predefined functions 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.21 Inherited commands and functions 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21.1 Automated procedures (APs) 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21.2 UCL library procedures and functions 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21.3 Command sequences 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dok.-Nr/ Doc. No.: COL–RIBRE–STD–0009Ausgabe /Issue: 2Überarbtg./ Rev.: BSeite/Page: 1

Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


1 INTRODUCTION

1.1 Identification and Scope

This is the Language Reference Manual for the Columbus High Level Command Language (HLCL),Document No.: COL–RIBRE–STD–0009 (previous Doc. No.: STD 1214 573).

1.2 Purpose

This document provides the language definition for HLCL. It serves the purpose of establishing the formalrequirements on the language, i.e. its syntax and semantics. It is particularly intended for the design anddevelopment of the HLCL interpreter.

Chapter 3 gives an overview on the Columbus Language Concepts: UCL and HLCL and their relationship,as well as the basic conceptual ideas that led to the definition of HLCL.

In chapter 4 the definition of the High Level Command Language is given.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


2 APPLICABLE AND REFERENCE DOCUMENTS

2.1 Applicable Documents

The following documents form a part of this specificaiton to the extent specified here. In case of conflictthis specification shall be superseding. The exact actual status of the documents listed below is to beobtained from the contractual baseline status list.

2.1.1 User Control Language (UCL) Reference Manual

COL–RIBRE–STD–0010, Issue 4/A, 31.10.2001

2.2 Reference Documents

None identified.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


3 LANGUAGE CONCEPTS

3.1 HLCL and UCL

The High Level Command Language (HLCL) is the interactive counterpart of the User Control Language(UCL). UCL acts as a pure programming language: automated procedures and libraries are edited off–line,compiled and kept in the database for later on–line execution.

HLCL is an interactive command language used in different environments in the Columbus Ground Sys-tem: within interactive sessions, users type commands which are executed immediately by the HLCL com-mand interpreter.

UCL and HLCL are, in principle, lexically, syntactically and functionally identical. They are essentiallythe same language. There are, however, specific features, extensions and restrictions for both languagedomains.

This document defines the HLCL specific differences between UCL and HLCL. It does not describe thebasic language itself as given by the UCL Language Reference Manual. The UCL RM is considered partof this document.

3.2 General principles

It should be noted as an obvious fact that the design principles for an interactive command language likeHLCL are naturally different from those of a programming language like UCL:

• While programs in a programming language are typically written only once, but read a lot of times(even by different people), commands are typically typed repeatedly and never read again. So while,for a programming language, readability is a major requirement, and features that ease writing playa minor role (e.g. optional parameters) or should even be entirely forbidden (e.g. abbreviations), thecontrary holds for command languages. Here easy input is a major topic.

• While the program logic of e.g. a UCL program must be completely defined before actual executionand allows no interactive modifications at run time, command language sessions have totallycontrary characteristics: the session logic is interactively developed (possibly on an experimentalor trial and error basis) during the session. Therefore flexibility and interactive assistance are majorrequirements.

• While in the case of UCL programs full checks on availability and compatibility of accessedresources must be performed at mission preparation time, these checks are naturally on–lineconstituents of an HLCL session and role themselves as decision factors for the further sessiondevelopment.

• While run time efficiency is an important aspect for UCL programs, it is of less importance forHLCL sessions.

These principles have driven the definition of the HLCL specifics as described in this manual.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


3.3 Usage

HLCL may be used in a command window, i.e. where a user interactively types commands, or in any otherenvironment where commands are generated by software, e.g. in the synoptic displays environment usedfor verification, integration, and checkout.

When used in a command window, it is assumed that the command window software will provide for theusual support services like command history, command line editing, and command interrupt. This manual,however, defines only the language itself, not its use in any specific environment.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4 LANGUAGE DEFINITION

4.1 Sessions

A session is the basic commanding and execution environment for interactive operation. It is, in a certainsense, the interactive counterpart of a UCL automated procedure (AP). Within a session the user typesmore or less the same commands in the same form that may appear in an AP in UCL. There are, however,some essential differences:

• There is no syntactic frame that encloses a session, like e.g. a session header, or the begin and endkeywords. When logged in, the user is free to start typing commands.

• There is no required order or grouping of commands, e.g. declarations, import statements and anyother commands may be mixed arbitrarily. Declared objects may even be deleted.

• The underlying application software may make its own specific language additions available, suchas login and logout command sequences and application specific types, commands and functions.All additions will, however, conform to the basic language definition.

4.1.1 Debug mode

The user may switch between normal mode and debug mode by setting the predefined variable DEBUGto false or true, respectively. In normal mode commands are executed immediately. In debug mode eachcommand is first displayed in expanded and evaluated form, i.e. abbreviations are removed, expressionsare evaluated, defaults are inserted and all parameters are given in named notation. The user is then askedfor explicit confirmation before executing the command.

4.1.2 Command logging

Interactively typed commands may be collected in a log file to automatically build a command sequencewhich may then be executed again. For this purpose the user can open and close command log files withthe OPEN and CLOSE commands. Whenever a new file is opened, a new command sequence is built. TheOPEN command allows for different logging options. Command logging mode can be controlled with thepredefined variable KEEP. When keep is set to true (and a log file is open), all interactively entered com-mands are logged in the currently open log file, when set to false, commands are not logged. This may beused for selective command logging.

Note that this command logging mode provided by the HLCL Interpreter itself is independent of any log-ging functionality that may be provided by the applications using the HLCL Interpreter.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.2 Command Sequences

A command sequence is a series of single commands put in a file or in the database. They may be usedto set up a certain working environment (define variables, constants, alias names etc.).

Command sequences may have parameters, they may be of any mode. A command sequence can be ex-ecuted at any time like a single command by using its file name or path name as the command name, andspecifying its parameters in the usual form, as for any other command.

A command sequence acts as a non–interactive session. It may contain any commands, in particular it maycontain calls to other command sequences. The execution of command sequences thus forms an executionhierarchy whose upper level is the session. When a command sequence is started, execution at the currentlevel is blocked until the called sequence has completed its execution. Execution is then resumed at thepoint of call.

This implies that during execution of a command sequence no commands can be given from the keyboard.The execution can, however, be interrupted by pressing an interrupt key combination: the currently ex-ecuted command is then cancelled, and control immediately returns to the session. The sequence is sus-pended but remains loaded and can be resumed at any time with the RESUME command.

4.2.1 Command sequence syntax

The command sequence syntax resemblesthat of an automateed procedure. A verysimilar framework separates a sequence inoptional imports and declarations beforeits header, a local declaration part and aglobal part. And it may have parameters.

The following differences exist, however:

• The keyword procedure is replaced by the keyword sequence . The name given after the key-word is implicitly declared as an alias for the pathname (for sequences kept in the database) or forthe file name (for sequences kept in files).

• The local declaration part, including the terminating begin keyword, is optional and may beomitted. Items declared here, as well as the sequence parameters, are local to the sequence. Theyhide imported items with the same name, and they are accessible only within the commandsequence.

• The rest of the sequence is global and can be regarded as a piece of the session. A grouping of com-mands is not required, import statements, declarations and other commands may be mixedarbitrarily, imports and declarations may even be embedded in control structures. Declarations madehere create global objects at the session level. Items declared in the session are visible only here.

• Within a command sequence the same rules apply as in a session, but some session specific relax-ations and extensions are not valid:

• Abbreviations are not allowed.

• The end of a line is not a command terminator, i.e. commands must be terminated with a semi-colon and may be formatted over several lines if desired.

• Only optional parameters may be omitted.

• Engineering units must not be omitted.

imports, declarations (no variables)

sequence name ( parameters );

local declaration part (imports, declarations)

begin

global part (imports, declarations, commands)

end name;

optional

optional


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.2.2 Echo mode

When the predefined variable ECHO is set to true, commands executed from a command sequence areechoed on the screen. When ECHO is not set, only start and completion of command sequences are re-ported.

4.2.3 Error handling in command sequences

When an error occurs in a command sequence, the effect depends on the predefined TRAP variable. If errortrapping is on, an error within a command in a command sequence interrupts the command sequence, asif the interrupt key combination had been pressed. Execution can then be resumed with the RESUME com-mand.

4.2.4 Single step mode

Command sequences may be executed in single step mode. This is controlled via the predefined variableSTEP. When this variable is set to true, each command from a command sequence must be confirmed be-fore execution. When it is set to false, commands are executed automatically without confirmation.

Note that imports and declarations before the sequence header cannot be single–stepped. They areevaluated before the sequence starts, because they are needed to determine the parameter list.

4.3 Command lines

In UCL a statement is terminated with a semicolon, and the line structure is irrelevant. In HLCL the semi-colon is a command terminator, as well. But the end of an input line acts as an additional command termin-ator. This means that practically the semicolon may be omitted when single commands are entered, eachon a separate line. It must not be omitted, however, between two commands on the same line.

Examples:

PUT X –– single command on a line, no semicolon needed

X := Y + Z; PUT X –– two commands on a line, separated by semicolon


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.4 Command and function classes

HLCL provides most of the basic language material of UCL, as well as HLCL specific extensions. InHLCL, statements and other syntactic entities are usually referred to as commands. The basic UCL state-ments constitute the primary command set of HLCL.

An essential characteristic of HLCL is that it does not restrict itself to a predefined set of commands, butthat it is able to incorporate (”inherit”) all executable objects in the Columbus database and make themtransparently available as commands or functions, respectively. The following command and functionclasses can be distinguished:

• Import statements

As defined in the UCL Reference Manual.

• Declarations

As defined in the UCL Reference Manual, but HLCL does not support the declaration of proceduresand functions.

• Assignments


• Standard UCL procedures and functions (”intrinsics”)


• Simple commands and functions

These are predefined commands and functions. A basic set of primary commands and functions isdescribed in this paper, but within a given application environment (EGSE, simulator, on–board)the relevant application may add application specific commands and functions. Thus the primarycommand set is made up of

• basic commands and functions predefined in HLCL

• application specific commands and functions added by an application.

• Inherited commands and functions

All executable objects in the Columbus database are accessible as quasi–HLCL commands or func-tions. They are activated in the same syntax as primary commands and functions. Inherited com-mands and functions comprise

• automated procedures (APs, are commands)

• UCL library routines (are commands and functions, respectively).

• Command sequences

Command sequences kept in the database or in files may be called like single commands (see 4.2).

• A help facility.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.5 Import

The import statement is identical to that in UCL.

4.6 Declarations

The UCL declarations are fully available in HLCL.

HLCL extends the alias declaration: an alias may also be assigned to a string constant. When used, thestring alias must designate the name of a file that contains a command sequence. The intended effect isto be able to call a command sequence contained in a file by a simple name.

Example:

alias SHUTDOWN = ”/usr/columbus/users20/vicos/shutdown.hlcl”

4.7 Assignment

Assignments are identical to UCL assignments.

4.8 Standard procedures & functions

All the procedures and functions defined in the UCL Reference Manual may be called from HLCL, pro-cedures becoming commands. HLCL predefines additional standard procedures.

procedure DELETE

HLCL allows to delete (undeclare) a user declared object (constant, variable, type, ...) with the standardprocedure DELETE. Predefined objects and objects imported from libraries cannot be deleted.

DELETE identifier deletes a declared object (constant, variable, type, ...)

DELETE unit deletes a unit. unit must be a single unit identifier in unit brackets,e.g. [km]

procedure TRIGGER

This procedure triggers objects of type PULSE and BURST_PULSE. It has two forms:

TRIGGER pulse triggers a PULSE object,or a BURST_PULSE object, incrementing its value by 1.

TRIGGER burst_pulse, increment triggers a BURST_PULSE object, incrementingits value by some selectable increment > 0.

function IMPORTED

This functions tests whether an importable item (e. g. a library) has been imported:

IMPORTED(p) returns the Boolean value TRUE if the database item denoted by pathname p has been imported in the current session, else returns FALSE.The pathname p must denote an importable item, e. g. a library.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.9 Simple commands

A simple command is essentially identical to a UCL procedure call, i.e. it is invoked with its name, fol-lowed by its parameter list, if any.

HLCL relaxes the UCL syntax rules to support easy typing:

• Parameter lists are given without the enclosing parentheses.

• All parameters (except open array and open string out parameters) may be omitted, an appropriatedefault action is then taken:

• For optional parameters the defined default value is taken.

• Mandatory in and in out parameters are prompted for.

• For pure out parameters the returned value is displayed.

A few simple commands are predefined. This basic command set may be extended by various applicationswith application specific command sets.

4.10 Return command

The return command (without a value) is only allowed in command sequences. It terminates executionof the command sequence and returns control to the caller.

4.11 Structured commands

The HLCL structured commands identically correspond to the UCL control structures (if , case , loop ,while , for , repeat ). They are only allowed in command sequences.

4.12 Expressions

Expressions are identical to UCL expressions.

4.12.1 Path names

HLCL extends the path name syntax. Path names may start with \\ instead of just \ . Such path namesare implicitly understood to be a subpath of the default path defined in the varible DEFAULT_PATH, i.e.they are implicitly prefixed with the current value of DEFAULT_PATH.

4.12.2 Type conversions

HLCL defines new type conversions (see 4.17):

PULSE –> BOOLEANBURST_PULSE–> UNSIGNED_INTEGER.

4.12.3 Conversion to string

HLCL allows type conversions from any type to string types. In the case of named string types this followsthe usual conversion syntax. A general conversion to string may also be written as

string ( expression)


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.13 Type overloading

HLCL relaxes the rule that a parameter is bound to exactly one type: parameters of primary commands(basic as well as application specific) may be of more than one type. Such parameters are said to be (type)overloaded. An overloaded parameter accepts values of any of its types. If it is an open array parameter,the list of values may contain a mixture of values of any of the allowed types.

4.14 Units of measure

The HLCL unit of measure concept is identical to the corresponding UCL concept. The strict conformancerules of UCL are, however, relaxed:

• A unitized variable may be assigned a unitless value. The value is then implicitly unitized with thesame unit as the variable.

• A unitless variable may be assigned a unitized value. The unit is then ignored.

• A unitless in parameter may be passed a unitized value. The unit is then ignored.

• A unitized in parameter may be passed a unitless value. The value is then implicitly unitized withthe same unit as the parameter.

• A unitized (in ) out parameter may be passed a unitless variable. Within the procedure or function,the value of the variable is then assumed to be of the same unit as the parameter.

• A unitless (in ) out parameter may be passed a unitized variable. The unit of the variable is thenignored within the procedure or function.

4.15 Abbreviations

All identifiers may be abbreviated arbitrarily, as long as they remain unique, simply by cutting off wordtails. In compound identifiers (i.e. names composed of name parts separated by underscores) the nameparts can be abbreviated separately like simple identifiers, as long as the whole name remains unique.

Examples:

Identifier Possible abbreviations VOLTAGE VOLTAG, VOLTA, VOLT, VOLASSIGN_PICTURE ASS_PIC, ASS_P, A_P, ASSSEND_TM_MESSAGE SEND_TM, S_TM_MES, S_T_M

In general, UCL reserved words (keywords) cannot be abbreviated. But, for convenience, if the first wordof a command is a keyword, e.g. in declarations (constant , type , variable , alias , unit ) or inthe import command, then it may be abbreviated.

Within a command sequence, abbreviations are not allowed.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.16 Help facilityHLCL provides a help facility that allows the user to obtain a short description on an object given by itsname, an engineering unit, or on the value of an expression.

Syntax: Help ::= ”?” [ Item ]Item ::= Object [ ”...” ] [ Constraint ] | Expression | UnitObject ::= Qualified_Identifier | NameConstraint ::= ”(” Identifier { ”,” Identifier } ”)”

A single question mark displays a list of all (predefined or declared) identifiers.

The effect of a question mark applied to a (qualified) identifier depends on the identifier. If it is ambiguous,then it is assumed to be an abbreviation and a one–line information is displayed for all objects whose namematches the abbreviation. This line contains the value of the object, if any. If the identifier is unique, a moredetailed information for that object is displayed:

• For a command or function name a short command/function information is displayed, comprisingthe parameter list, and for each parameter the type(s), parameter mode and default value, if any.

• A library procedure/function is treated as a simple command/function.

• For an alias, in addition to the value of the alias an information on the designated object is displayed,depending on the type of object.

• For all other objects a short identification of the object is displayed, together with its value, if any.

A question mark applied to an expression displays the expression with all abbreviations expanded, to-gether with its value.

For a unit, its definition in terms of the seven basic SI units is displayed.

The effect of a question mark applied to a database path name depends on the type of item:

• For a virtual item (non–end–item) a one–line information for each of its children is displayed.

• For a library path name a list of the library contents is displayed.

• For other items the general attributes are displayed together with the parameter list, if any.

A path name may be constrained to a subset of item types by giving a list of possibly abbreviated item typesin parentheses.

The recursive indicator (’... ’) requests information to be displayed recursively:

• For a unique (qualified) identifier an information line is displayed for the identifier itself and for allidentifiers referenced in its definition. This process is repeated recursively until all identifiers havebeen resolved.

• For a virtual database item not only its children are displayed, but also the children of the (virtual)children, and so on recursively down to end item level.

Note that values of low–level types (BYTE, WORD, LONG_WORD) are shown as byte string literals.

Examples:

? –– Display list of all identifiers? ASS_PIC –– Display details of command ASSIGN_PICTURE? ASS_PIC ... –– Display details of ASSIGN_PICTURE recursively? MIN (INTEGER) –– Display value of an expression? (X + y) * Z –– Display value of an expression? [km/h] –– Display [km/h] in terms of [m/s]? \APM\GROUND\VICOS... –– Display database subtree recursively? \APM\GROUND... (UCL,HLCL) –– Display all UCL and HLCL items in database subtree


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.17 Predefined types

The HLCL data types are identical to the UCL types. HLCL predefines the following additional types, anapplication may add its own application specific types.

type OBJECTS

This is an enumeration type that defines the objects that may be listed with the LIST command.

type OBJECTS Objects to be listed (see LIST command): = (CONSTANTS, all constants (including enumeration literals)

LITERALS, all enumeration literals (subset of CONSTANTS)VARIABLES, all variablesTYPES, all typesALIASES, all alias namesPARAMETERS, all parameters of the currently running sequenceUNITS, all measurement unitsCOMMANDS, all commands (including intrinsic and other procedures)FUNCTIONS, all functions (including intrinsic functions)INTRINSICS , all standard (”intrinsic”) procedures and functionsIMPORTS, all imported UCL librariesSUBTREES, the set of database subtrees authorized for the userITEM_TYPES, the set of database item types authorized for the userCALL_STACK) the stack of loaded command sequences

type PULSE

A pulse is a binary event used by a simulator (CSS) function block to trigger the execution of anotherfunction block. A function block receiving a triggered parameter of type PULSE is automaticallyactivated within the next time frame.

Objects of type PULSE are only defined in the database. They cannot be declared, have no operationsand cannot be assigned. They are initially cleared and may be triggered with the standard procedureTRIGGER. Triggering a PULSE object changes its value. The value of a PULSE object may be ob-tained by converting it to BOOLEAN. The conversion yields true for triggered objects, otherwisefalse.

type BURST_PULSE

A burst pulse is a counting event used by a simulator (CSS) function block to trigger the executionof another function block, like a pulse. A function block receiving a triggered parameter of typeBURST_PULSE is automatically activated within the next time frame. When triggered, it does notjust become set but, rather, increments its value.

Objects of type BURST_PULSE are only defined in the database. They cannot be declared, have nooperations and cannot be assigned. They are initially cleared (i.e. they have value 0) and may be trig-gered with the standard procedure TRIGGER to increment thair value. The default increment is 1,greater increments may be requested as a second parameter to TRIGGER. The value of a PULSEobject may be obtained by converting it to UNSIGNED_INTEGER. The conversion yields a value> 0 for triggered objects, otherwise 0.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.18 Predefined variables

HLCL predefines some variables with a special meaning. These variables have an initial default value thatmay be changed by the user with an assignment.

variable DEFAULT_PATH: pathname := application defined

Wherever a path name is prefixed with \\ , the prefix is expanded with the current value of the vari-able DEFAULT_PATH. This variable has an initial value defined by the underlying application.

variable DEFAULT_NODE: pathname := application defined

The default node used to start APs and call library routines. This variable has an initial value definedby the underlying application.

variable ECHO: BOOLEAN := FALSE

This variable defines whether commands executed from command sequences are echoed on thescreen. If set to false, only start and stop of command sequences are reported. This variable is initiallyset to false.

variable TRAP: BOOLEAN := FALSE

This variable determines the error handling mechanism within command sequences. When set totrue, an error in a command sequence interrupts execution of the sequence and returns control to thesession. The sequence remains loaded and may be resumed with the RESUME command. When setto false, errors in a command sequence do not interrupt execution of the sequence.

variable STEP: BOOLEAN := FALSE

This variable selects single–step execution of command sequences. When set to true, each commandfrom a command sequence must be confirmed before execution.

variable DEBUG: BOOLEAN := FALSE

This variable selects debug mode. In debug mode all commands are displayed in expanded form (ab-brevations resolved, defaults inserted etc.), and confirmation is requested before execution.

variable KEEP: BOOLEAN := TRUE

This variable controls command logging mode. When set to true (and a log file is open), all interac-tively typed commands are logged in expanded form in a command log file (see the OPEN andCLOSE commands). When set to false, nothing is logged, even if a log file is open.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.19 Predefined commands

A set of primary commands is built–in to HLCL on a fixed basis. This basis comprises the differentcommand forms: declarations, assignments, simple commands, structured commands, and the helpcommand. This section lists only the simple commands that are specific to HLCL and therefore notcovered by the UCL LRM. Only the basic commands are listed here; for the different target environments,additional environment–specific commands may be added.

Each primary command is described in this section, giving its name, a short description and its parameterlist. For each parameter, its mode, name, type(s) and default value, if any, are given. Parameters with adefault value are optional.

4.19.1 Display commands

LIST Display list of objects

Display a list of all objects of a certain class. The list may be restricted to a specific scope.

Parameters:

in CLASS: OBJECTS

the class of objects to be displayed. It is given as a value of the predefined enumeration typeOBJECTS.

in SCOPE: pathname := \\

This parameter allows to restrict the list to objects of a specific library scope determined by thepath name of a library: only objects declared in that library are then listed. If no scope is given(\\ ), all scopes (i.e. the session and all imported libraries) are listed.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.19.2 Command sequence related commands

CHECK Check a command sequence

Check a command sequence for syntactical correctness. Note that problems resulting from executionof the command sequence in different session environments and from possibly violated semanticalconditions between actual parameters and between commands themselves cannot be checked.

Parameter:

in SEQUENCE: pathname | string

Name of the command sequence (path name if in the database, string if in a file).

SUSPEND Suspend execution of a command sequence

Suspend command sequence execution and return to interactive input. The sequence may later be re-sumed at the suspension point. This command can only be used within a command sequence.

RESUME Resume a suspended command sequence

Resume command sequence execution which was suspended by the SUSPEND command, by error oruser interrupt.

CANCEL Cancel the command sequence call stack

Remove the command sequence call stack, i.e all currently loaded (and suspended) command se-quences. This command can only be used interactively when no command sequence is active. RESUMEis then no longer possible.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.19.3 Input/output commands

These commands are intended for interaction with the user from within a command sequence.

GET Read input value from keyboard

Read a value from the keyboard, optionally write a prompt before reading. The type of the value is deter-mined by the actual parameter. Invalid input will be reported as an error, and reading will be repeateduntil a correct value has been read.

Parameters:

in PROMPT: string := ””

The prompt to be written.

out ITEM: any type

The item to be read.

PUT Display the value of an item

Display the value of the parameter as an output line on the screen. The parameter may be an expressionof any type. (Several items may be combined into a line by converting them to string and concatenatingthem with the + operator). Values of low–level types (BYTE, WORD, LONG_WORD) are shown as bytestring literals.

Parameter:

in ITEM: any type

The item to be displayed.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.19.4 Command logging commands

These commands are used to control command logging.

OPEN Open a command log file

Open a new command log file and generate a command sequence in it. The syntactical form of the com-mands in the command sequence to be generated may be specified by several parameters. This com-mand is only allowed when no log file is currently open.

Parameters:

in FILE: string

Name of the log file to be created.

in SEQUENCE: string

Name of the command sequence to be created in the log file.

in EXCLUDE: string := ””

List of commands to be excluded from logging. Command names are separated by comma orblank. Assignment is given as := , the help facility as ?, the different declaration statements asthe respective keyword.

in NAMED: BOOLEAN := TRUE

Specifies whether command parameters are to be generated in named notation.

in EVALUATED: BOOLEAN := FALSE

Specifies whether parameters are to be evaluated and given as values, or expressions are to bekept.

in FORMATTED: BOOLEAN := FALSE

Specifies whether commands are to be formatted with each parameter on a separate line, or unfor-matted with the whole command in one line.

CLOSE Close the command log file

The currently open command log file is closed, the generated command sequence is syntactically com-pleted first. This command is only allowed when a log file is currently open.


Datum/ Date : 23.2.1996

Datum/ Date: 31.10.2001

von/ of 19


4.20 Predefined functions

There are no predefined HLCL functions other than the standard functions described in the UCL ReferenceManual. For the different target environments (such as ground testing and checkout, simulation) additionalenvironment specific functions may be added to the basic ones.

4.21 Inherited commands and functions

The commands and functions described in previous chapters make up the basis of HLCL. A moreinteresting aspect of HLCL is its capability of dynamically extending its primary command and functionset by inheriting new commands and functions from the Columbus databases.

Since an HLCL command can be seen as a parameterised procedure (more generally: an executable objectwith a parameter list), any objects in the Columbus databases that have this same property can theoreticallybe addressed as HLCL commands, similarly for functions. The objects conforming to these conditions areautomated procedures (APs), UCL library procedures and functions and command sequences.

The following sections describe how these database objects are mapped onto HLCL commands andfunctions.

4.21.1 Automated procedures (APs)

Automated procedures are parameterised ”main programs” written in UCL and compiled into anintermediate code (I–Code) which is interpreted by I–Code interpreters residing in different nodes in thenetwork.

The APs have a path name which reflects their position in the database name tree, and a parameter list.An AP can therefore be mapped on an HLCL command, the path name acting as the command name, andthe parameter list obeying the HLCL parameter conventions. Activation of an AP can thus be expressedas an inherited quasi–HLCL command, e.g. :

\PAYLOAD\EQUIPMENT\UNIT_A\COMMAND MODE: 3

APs are executed on different nodes in a network. Several APs may be active concurrently, on differentnodes or on the same node. The node name is obtained from the predefined variable DEFAULT_NODE.

4.21.2 UCL library procedures and functions

UCL library procedures and functions are called like in UCL. The target node in the network is obtainedfrom the predefined variable DEFAULT_NODE.

4.21.3 Command sequences

Command sequences stored in the database can be called in the same form as an AP. They are immediatelyexecuted in the local workstation. For a description of command sequences see chapter 4.2.

2