Dok.-Nr/Doc. No.: CGS–RIBRE–STD–0002cs.astrium.eads.net/cgs/docs/manual/CGS738/HLCL_RM.pdf ·...

Dok.-Nr/ Doc. No.: CGS–RIBRE–STD–0002Ausgabe /Issue: 5Überarbtg./ Rev.: a

Datum/Date : 2009–02–01

Datum/Date: 2015–05–29

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.: CGS–RIBRE–STD–0002Previous Doc. No.:

Bearbeitet: CGS – Team Org. Einh.: TSOEC4 Unternehmen: AIRBUS DEFENCE & SPACEPrepared by: Orgin. Unit: Company:

Geprüft: Stephan Marz Org. Einh.: TSOEC4 Unternehmen: AIRBUS DEFENCE & SPACEAgreed by: Orgin. Unit: Company:

Genehmigt: Stephan Marz Org. Einh.: TSOEC4 Unternehmen: AIRBUS DEFENCE & SPACEApproved by: Orgin. Unit: Company:

Genehmigt: Org. Einh.: Unternehmen:

Approved by: Orgin. Unit: Company:

DOCUMENT CHANGE RECORD

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

Dok.-Nr/ Doc. No.: CGS–RIBRE–STD–0002Ausgabe /Issue: 5Überarbtg./ Rev.: aSeite/Page: I

Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of III


1/– 2002–02–01 First version

1/A 2002–06–03 2.1 Applicable documents updated

4.12.13 String conversions adapted to new UCL feature

1/B 2003–01–15 2.1 Applicable documents updated for UCL RM change

2/– 2003–03–04 4.2 New feature: HLCL proceduresPrivileges, authorization

2/A 2004–09–01 4.14 Entity types

4.16 New help operator “??”

2/B 2004–12–14 5 Privileges enheritance on subprogram level

2/C 2005–02–20 2.1.1 Document references updated

2/D 2005–06–08 2.1.1 Document references updated

2/E 2005–08–30 2.1.1 Document references updated

3/– 2005–12–01 2.1.1 Document references updated

3/A 2006–05–04 4.1.1, 4.14, 4.15 STRICT mode

4.19 New literal “PRIVILEGES” in type “OBJECT”(for “LIST PRIVILEGES”)

4/– 2008–11–01 Intermediate changes, not used

4/A 2009–02–01 Document references updated

5/– 2010–01–29 4.24 HLCL system libraries

4.16 Relaxations for measurement units removed

4.18 Extended help command for annotations

5/a 2015–05–29 4.21.4 Change parameter name for OPEN command fromSEQUENCE to SEQUENCE_NAME

Dok.-Nr/ Doc. No.: CGS–RIBRE–STD–0002Ausgabe /Issue: 5Überarbtg./ Rev.: aSeite/Page: II

Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of III


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 Strict and Non–Strict Mode 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Debug Mode 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Command Logging 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 Command Sequences 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Command procedures 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Open command sequences 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Echo Mode 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Error Handling in Command Sequences 8. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 Single Step Mode 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Command Lines 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Qualified Predefined Identifiers 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Command and Function Classes 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Import 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Declarations 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Assignment 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Standard Procedures & Functions 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 Simple Commands 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Return Command 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Structured Commands 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13 Expressions 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.13.1 Path Names 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.2 Type Conversions 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13.3 String Conversions 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.14 Type Overloading 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.15 Entity Types 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16 Units of Measure 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dok.-Nr/ Doc. No.: CGS–RIBRE–STD–0002Ausgabe /Issue: 5Überarbtg./ Rev.: aSeite/Page: III

Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of III


4.17 Abbreviations 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.18 Help Facility 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.19 Predefined Types 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.20 Predefined Variables 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.21 Predefined Commands 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21.1 Display Commands 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21.2 Command Sequence Related Commands 18. . . . . . . . . . . . . . . . . . . . . . . . . 4.21.3 Input/Output Commands 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.21.4 Command Logging Commands 20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.22 Predefined Functions 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.23 Inherited Commands and Functions 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.23.1 Automated Procedures (APs) 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.23.2 UCL Library Procedures and Functions 21. . . . . . . . . . . . . . . . . . . . . . . . . . 4.23.3 Command Sequences 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.24 HLCL System Libraries 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Authorization, Privileges 24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dok.-Nr/ Doc. No.: CGS–RIBRE–STD–0002Ausgabe /Issue: 5Überarbtg./ Rev.: aSeite/Page: 1

Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


1 Introduction

1.1 Identification and Scope

This is the Language Reference Manual for the CGS High Level Command Language (HLCL), DocumentNo.: CGS–RIBRE–STD–0002. The first issue is derived from the Columbus documentCOL–RIBRE–STD–0009, issue 2/B. Changes to this base document are marked with change bars.

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 CGS Language Concepts: UCL and HLCL and their relationship, aswell 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 : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


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

CGS–RIBRE–STD–0001, Issue 5/–, 2010–01–29

2.2 Reference Documents

None identified.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


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 CGS based ground systems:within interactive sessions, users type commands which are executed immediately by the HLCL commandinterpreter.

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 : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


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 : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


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, i.e. 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 Strict and Non–Strict Mode

In interactive commanding, HLCL works in non–strict mode by default, which allows certain syntaxrelaxations (abbreviations) for simpler typing. In strict mode these relaxations are not supported. The usermay switch between strict and non–strict mode by setting the predefined variable STRICT to true or false,respectively.

4.1.2 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.3 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 enteredcommands are logged in the currently open log file, when set to false, commands are not logged. This maybe used for selective command logging.

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


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.2 Command Sequences

A command sequence is a series of single commands put in a file or in the database, much like an automatedprocedure (AP) in UCL.

Like an AP, a command sequence can be annotated. The annotation is given after the sequence header.

Command sequences may have parameters, which may be of any mode. A command sequence can beexecuted at any time like a single command by using its file name or path name as the command name,and specifying 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, including controlstructures, in particular it may contain calls to other command sequences. The execution of commandsequences thus forms an execution hierarchy whose upper level is the session. When a command sequenceis started, execution at the current level is blocked until the called sequence has completed its execution.Execution is then resumed at the point 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 currentlyexecuted command is then cancelled, and control immediately returns to the session. The sequence issuspended but remains loaded and can be resumed at any time with the RESUME command.

Within a command sequence, the same rules apply as in a session, it may contain any commands that wouldbe allowed in a session, and command parameters are not enclosed in parentheses. But some sessionspecific relaxations 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 semicolonand may be formatted over several lines if desired.

• Only optional parameters and parameters of mode out may be omitted.

There are two forms of command sequences:

• Command procedures have a closed scope, there is no access to the session from within procedures.

• Open command sequences have an open scope, their commands and declarations act as part of thesession.

4.2.1 Command procedures

A command procedure is syntactically identical to a UCL automated procedure. The name given after theprocedure keyword is implicitly declared as an alias for the pathname (for procedures kept in thedatabase) or for the file name (for procedures kept in files).

Before the procedure header there is an optional import and declaration section. It may declare units, types,constants and aliases. Items declared here belong to the same name scope as the global declarations withinthe procedure.

Command procedures may be imported in other command procedures or open sequences, and in sessions,but procedures cannot import open sequences. Importing a procedure makes the items declared before theheader, as well as the implicit alias, directly visible.

Command procedures must not call open sequences, and procedures kept in the database must not callprocedures kept in files.

Command procedures have dependencies and conditions on compilation order like an automatedprocedure.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.2.2 Open command sequences

The command sequence syntax resemblesthat of a procedure, the procedurekeyword being replaced by sequence .A very similar framework separates asequence in an optional imports/declarationsection before its header, a local declarationpart and a global part.

The following points are specific to opensequences:

• 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. Similarly, items imported here take effect only within the command sequence.

• The rest of the sequence is global and can be regarded as a piece of the session. A grouping ofcommands 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.

Since open command sequences have an open scope, they may be used to set up a certain workingenvironment (define variables, constants, aliases etc., and import libraries).

For open command sequences no compilation dependencies are maintained. Compiling a sequences willjust perform a syntax check.

imports, declarations (no variables)

sequence name ( parameters );

local declaration part (imports, declarations)

begin

global part (imports, declarations, commands)

end name;

optional

optional


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.2.3 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 arereported.

4.2.4 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 RESUMEcommand.

4.2.5 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 confirmedbefore 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 thesemicolon is a command terminator, as well. But the end of an input line acts as an additional commandterminator. This means that practically the semicolon may be omitted when single commands are entered,each on 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

4.4 Qualified Predefined Identifiers

Like in UCL, predefined identifiers may be given in their qualified form with a leading dot. This appliesboth to identifiers predefined in UCL (e. g. .INTEGER, .MIN , .LENGTH) and to identifiers predefinedin HLCL, regardless of whether they are basic HLCL identifiers or defined by the specific application(e. g. .PUT, .GET, .OBJECT).


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.5 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 UCLstatements 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 Mission 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 Mission Database are accessible as quasi–HLCL commands orfunctions. They are activated in the same syntax as primary commands and functions. Inheritedcommands 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 : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.6 Import

The import statement is identical to that in UCL.

4.7 Declarations

The UCL declarations are fully available in HLCL.

Like in UCL, annotations can be given with declared items, both in command sequences and in interactivecommands. The extended help operators (see 4.18) display the annotations together with the itemdescription.

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.8 Assignment

Assignments are identical to UCL assignments.

4.9 Standard Procedures & Functions

All the procedures and functions defined in the UCL Reference Manual may be called from HLCL,procedures 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, incrementtriggers 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 : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.10 Simple Commands

A simple command is essentially identical to a UCL procedure call, i.e. it is invoked with its name,followed 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.11 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.12 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.13 Expressions

Expressions are identical to UCL expressions.

4.13.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.13.2 Type Conversions

HLCL defines new type conversions (see 4.19):

PULSE –> BOOLEANBURST_PULSE–> UNSIGNED_INTEGER.

4.13.3 String Conversions

HLCL does not restrict string conversions to a subset of types, as in UCL. String conversions may beapplied to all types, including structured types. Note that the resulting strings are in UCL I/O format.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


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

Only types with distinct base types whose values can be lexically distinguished can be overloaded.

4.15 Entity Types

Parameters of HLCL commands may be of an entity type. The values of such types are entities of thelanguage, like e. g. variables, procedures/functions or measurement units. Different entity types can beoverloaded and restricted to specific entity classes, e. g. a parameter may require that only variables,functions and pathnames of a specific item type may be passed. Entity types can only be predefined, notdeclared by the user.

4.16 Units of Measure

The HLCL unit of measure concept is identical to the corresponding UCL concept.

4.17 Abbreviations

In interactive command windows, all identifiers may be abbreviated arbitrarily, as long as they remainunique, simply by cutting off word tails. In compound identifiers (i.e. names composed of name partsseparated by underscores) the name parts can be abbreviated separately like simple identifiers, as long asthe 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.

Abbreviations are not available in strict mode (see 4.1.1),


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.18 Help Facility

HLCL 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 ]

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

A single question mark treats a given identifier as a potential abbreviation and finds all matchingcandidates, a double question mark treats it as a unique, unabbreviated identifier.

The simple operators ? and ?? omit the annotation defined with the given object, whereas the extendedoperators ?... and ??... add the annotation to the output.

A single or double question mark without an item 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,together 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.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


Examples:

List of all identifiers

? –– Display list of all identifiers?? –– Display list of all identifiers

List of all identifiers, including annotations

?... –– Display list of all identifiers, including annotations??... –– Display list of all identifiers, including annotations

Help for an abbreviated identifier

? ASS_PIC –– Display details of command ASSIGN_PICTURE? ASS_PIC ... –– Display details of ASSIGN_PICTURE recursively

Help for a unique identifier

?? ASS –– Display details of unique identifier ASS?? ASS ... –– Display details of unique identifier ASS recursively

Help including annotation

?... ASS_PIC –– Display details of ASSIGN_PICTURE, show annotations?... ASS_PIC ... –– Display details of ASSIGN_PICTURE recursively, show annotations

Help for expressions

? MIN (INTEGER) –– Display value of an expression? (X + y) * Z –– Display value of an expression

Help for unions

? [km/h] –– Display [km/h] in terms of [m/s]?... [km/h] –– Display [km/h] in terms of [m/s] , show annotation

Help for database objects

? \APM\GROUND\VICOS... –– Display database subtree recursively? \APM\GROUND... (UCL,HLCL) –– Display all UCL and HLCL items in database subtree


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.19 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 sequencesPRIVILEGES) all defined system and user privileges

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 beobtained 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 betriggered with the standard procedure TRIGGER to increment thair value. The default increment is1, 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 : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.20 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 thevariable 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(abbrevations 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), allinteractively typed commands are logged in expanded form in a command log file (see the OPENand CLOSE commands). When set to false, nothing is logged, even if a log file is open.

variable STRICT: BOOLEAN := FALSE

This variable controls strict and non–strict mode. When set to true, interactive commanding worksin strict mode, i. e. abbreviations and omission of engineering units is not allowed. When set to false,these relaxations may be used.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.21 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.21.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 type OB-JECTS.

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. The database scopeis represented by the root path name (\ ). If no scope is given (\\ ), all scopes (i.e. the session andall imported libraries) are listed.

Please note that LIST with the SCOPE parameter omitted will not list the database scope for aliases,since the database may predefine a large number of aliases. In order to list the database scope, give theesplicit scope (\ ):

LIST ALIASES, \


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.21.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 beresumed 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) commandsequences. This command can only be used interactively when no command sequence is active. RE-SUME is then no longer possible.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.21.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. Input is restricted to scalartypes. The type of the value is determined by the actual parameter. Invalid input will be reported as anerror, and reading will be repeated until a correct value has been read. If the ITEM parameter is omitted,and thus no target type can be deduced, the input value is assumed to be a character string.

Values must be input in UCL I/O format.

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 are ouptut in UCL I/O format.

Parameter:

in ITEM: any type

The item to be displayed.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.21.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 thecommands in the command sequence to be generated may be specified by several parameters. Thiscommand is only allowed when no log file is currently open.

Parameters:

in FILE: string

Name of the log file to be created.

in SEQUENCE_NAME: 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, orunformatted 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 syntacticallycompleted first. This command is only allowed when a log file is currently open.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.22 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.23 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 Mission Database.

Since an HLCL command can be seen as a parameterised procedure (more generally: an executable objectwith a parameter list), any objects in the Mission Database 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.23.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.23.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.23.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.


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


4.24 HLCL System Libraries

Since any application that instantiates and uses an HLCL Interpreter can define its own specific primarycommands, functions, types etc. in addition to the predefined items described in previous sections,different interpreters in different environments typically have different application specific command sets.This causes a problem when compiling HLCL command sequences with the HLCL Compiler. Thecompiler, of course, cannot know the specific command set of the application for which a commandsequence is intended.

Application specific commands, functions, types etc. can be made available to the HLCL Compilerthrough HLCL system libraries, which can only be imported in HLCL command sequences andprocedures. An HLCL system library is syntactically identical to a UCL system library, but it allows todeclare HLCL specific objects. HLCL specific declarations are

• type overloading (4.14)

• entity types (4.15, currently not supported)

When an HLCL system library is imported in a command sequence or procedure, the imported items aretreated as predefined items in the command sequence/procedure, not as items imported from an externallibrary, according to their nature in interactive commanding. This has consequences for

• visibility: Predefined items hide imported items.

• qualified notation: Predefined items are qualified with a single dot.

Type overloading ( type union )

Overloading of types for a subprogram (command/function) parameter is expressed with the unionkeyword:

union

an unconstrained type union, any type is accepted. If an untyped value is passed as parameter, it willbe interpreted as a string of Byte .

union ( type_list)a constrained type union, only types from the type list are accepted.

array of union

an open list of an unconstrained type union (unconstrained heterogeneous list).

array of union ( type_list)an open list of a constrained type union (constrained heterogeneous list).

type_list is a comma separated list of type names, including the open types string , statecode andpathname .

Example:

procedure Proc (X : union ; –– unconstrained type union Y : union (Integer, statecode )); –– constrained type union


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


Example:

The following example HLCL system library declares the predefined items described in the previoussections. It can be understood as being implicitly imported in any HLCL command sequence or procedure.

library HLCL_Library;

type Objects = (Constants, Literals, Variables, Types, Aliases, Parameters, Units, Commands, Functions, Intrinsics, Imports, Subtrees, Item_Types, Call_Stack); <– Objects to be listed

procedure List ( in Class : Objects; in Scope : pathname := \\); <– Display list of objects

procedure Check ( in Sequence : union ( pathname , string )); <– Check a command sequence procedure Suspend; <– Suspend current command sequence

procedure Resume; <– Resume suspended command sequence

procedure Cancel; <– Cancel command sequence

procedure Get ( in Prompt : string := ””; out Item : union ); <– Read input

procedure Put ( in Item : union ); <– Display value of an expression procedure Open ( in File : string ; in Sequence : string ; in Exclude : string := ””; in Named : Boolean := True; in Evaluated : Boolean := False; in Formatted : Boolean := False); <– Open command log file

procedure Close; <– Close command log file

end HLCL_Library;


Datum/ Date : 2009–02–01

Datum/ Date: 2015–05–29

von/ of 24


5 Authorization, Privileges

Whenenver any of the following actions is performed in HLCL:

• starting an automated procedure (AP),

• calling a guarded library procedure or function,

• passing a pathname as a guarded parameter,

• importing a library,

• assigning a value to a software variable or passing a software variable as an out or in out parameter,

a check is made that the user has all privileges required by the accessed item. If a required privilege ismissing, the intended operation is denied.

Please note that a procedure or function call is guarded either if the subprogram is explicitly marked asguarded in its declaration, or if it accesses any guarded entities.

Privileges are configured in the database. See the system documentation for the concept and handling ofprivileges.

For a description of privilege handling in UCL see the UCL Reference Manual (2.1.1).2

Date post:	29-Jul-2018
Category:	Documents
Upload:	nguyenliem
View:	214 times
Download:	0 times