A modeling language to support the interoperability of global navigation satellite systems

Abstract

The availability of multiple Global Navigation Satellite Systems (GNSS) will offer the opportunity to provide seamless navigation services and improved positioning performance. However, before this opportunity can be exploited, a number of issues need to be solved to ensure the compatibility and interoperability of existing GNSS. In particular, the GNSS interoperability can be technically defined as the capability of receivers to compute their global position using two or more GNSS signals. This capability can be more effectively achieved if Signal-In-Space interface specifications are available in a consistent, unambiguous, and possibly standard format, which can support engineers to design interoperable receivers. We aim to support the design of interoperable receivers with the introduction of the Interface Communication Modeling Language (ICML), a graphical language for the formal specification of Signal-In-Space interfaces. The ICML language enables receiver engineers to specify these interfaces at different levels of abstraction, such as analog signal or binary data. In addition, the ICML language also supports the specification of conversion routines between adjacent levels, for the representation of the dynamic aspects—e.g., convolution and encryption processes—of the interface specification. As such, the ICML language proposes an alternative format to textual-based interface specifications and can possibly integrate with the ongoing trend of the Model-based Systems Engineering approaches. We present the structure of the framework implementing the language and an example ICML-based specification for a simplified and reduced version of the Galileo Freely Accessible Navigation (F/NAV) message. The language metamodel is also attached for technical reference. An important caveat: no endorsement is made for the use of the ICML language for the official Galileo Signal-In-Space interface specification.

Appendix: ICML structure metamodel

The structure metamodel defines a specialization of the UML language for the specification of Signal-in-Space interfaces. Central to the metamodel is the “Message Structure” Class, which definition is shown by the Class Diagram in Fig. 21. This diagram defines that message structure is to be specified at five levels, as above presented. Specifically, the “Message Structure” Class is associated with the “Data Definition Message Structure” Class, for the Data Definition Level; the “Data Binary Coding Message Structure Definition” Class, for the Binary Coding Level; the “Logical Binary Message Structure” Class, for the Logical Binary Structure Level; the “Physical Binary Message Structure” Class, for the Physical Binary Coding; and the “Signal Structure” Class, for the Physical Signal. Within an ICML-based specification, these Classes can also be associated with examples messages at the respective levels, as defined by the “value” associations.

Fig. 21

Central view of the ICML Structure metamodel

Each of the above Classes has been defined on a set of basic Classes, which are shown by the Class Diagrams in Fig. 22 and Fig. 23, respectively, for the Classes directly associated with the “Message Structure” Class and to the “Message” Class. These basic Classes are “Bit,” “Sequence of Bits Values” and “Sequence of Bits Structure.” The “Bit” Class represents the smallest unit of digital data that can be represented, that is, digital values 0 or 1. Similarly, the “Sequence of Bit Values” Class represents a binary string in the form of an ordered list of “Bit” Classes. Differently, the “Sequence of Bit Structure” Class represents the structure for sequence of bits values, including the number of bits composing a sequence and the sequence name, for example.

Fig. 22

Definition of the “Sequence of Bits Values” classes

Fig. 23

Definition of the “Sequence of Bits Structure” Classes

Data definition level

At this level, the metamodel defines the Classes for the logical specification of both application and control data. As shown by the Class Diagram in Fig. 24, the following Classes are defined: “Data Item Structure,” “Data Item Semantics,” “Data Item Pragmatics,” “Simple Data Item,” “Object,” “Numeric Simple Data Item,” “Number,” “Complex Data Item,” “Message Application Data Structure,” “Message Control Data Structure,” and “Message Data Definition Structure.” The “Data Item Structure” Class, which is central to this level, is characterized by the “name” attribute, indicating the name of the data item. This Class can also be associated with the “Data Item Semantics” and “Data Item Pragmatics” Classes, which can respectively convey the semantic and pragmatic definitions of any specialization of the “Data Item Structure” Class. The “Simple Data Item” Class specializes the “Data Item Structure” Class to represent a data item that does not aggregate multiple data items. The “Object” Class is an admissible data value for the “Simple Data Item” Class. Similarly, the “Number” Class specializes the “Object” Class for the representation of numerical values. Next, the “Numeric Simple Data Item” specialized the “Simple Data Item” Class for numerical data, constraining the “data value” associated with the “Number” Class. The “Numeric Simple Data” Class is also associated with the “SysML Measurement Unit” Class to indicate the measurement unit for the “data value” attribute. The “Complex Data Item” Class specializes the “Data Item Structure” Class to represent a data item that can aggregate multiple data items. The “Message Application Data Structure” Class specializes the “Complex Data Item” Class to represent the conceptual definition of the application data. Similarly, the “Message Control Data Structure” Class specializes the “Complex Data Item” Class to represent the conceptual definition of the control data. Finally, the “Message Data Definition Structure” Class can thus be defined as the aggregation of the “Message Application Data Structure” Class and of the “Message Control Data Structure” Class.

Fig. 24

Definition of the “data item” Classes

Binary coding data level

At this level, the metamodel defines the Classes for the specification of binary sequences representing level 5 data. As shown by the Class Diagram in Fig. 25, the metamodel defines the “Binary Data Item Structure” Class and the “Binary Data Item Interpretation” Class, both central to this level. The “Binary Data Item Structure” Class represents the structure of the binary sequences at this level and is also associated with the “Binary Data Item Interpretation” Class, which defines the pragmatic description. No semantics is directly associated with the “Binary Data Item Structure” Class as it coincides with the semantics associated with the “Simple Data Item” Class.

Fig. 25

Definition of the “Binary Data Item Structure” Class

The “Binary Data Item Interpretation” Class has been further specialized to offer a more accurate level of interface specification, as shown by the Class hierarchy defined by the Class Diagram in Fig. 26. The hierarchy also uses the following support Classes: “Scale Factor” and “Shift Factor.” The “Scale Factor” Class represents the multiplier number to be used in the below numerical interpretations. The “Shift Factor” Class analogously represents the addendum number to be used in the below numerical interpretations.

Fig. 26

Definition of the “Binary Data Item Interpretation” Classes

The hierarchy defines the following Classes: “Simple Binary Interpretation,” “Numerical Binary Data Interpretation,” “Natural Binary Data Interpretation,” “Real Binary Data Interpretation,” “Fixed Point Binary Data Interpretation,” “Tabular Binary Interpretation,” “String Tabular Binary Interpretation,” and “Range.” The “Simple Binary Interpretation” Class represents the interpretations that can be applied to all the possible binary values in the sequence. On the left branch of the hierarchy, the “Numerical Binary Data Interpretation” Class specializes the “Simple Binary Interpretation” Class and provides the basis for all the numerical interpretations. The “Numerical Binary Data Interpretation” Class is also associated with the “SysML Unit” Class, which indicates the measurement unit for the data. In addition, this Class is also characterized by the “unsigned” attribute—whether the sequence represents signed or unsigned number—and the “format” attributes—the coding standard for the sequence. Next, the “Natural Binary Data Interpretation” specializes the “Numerical Binary Data Interpretation” Class for the interpretation of sequences representing integer numbers. This Class is also associated with the above mentioned “Shift Factor” and “Scale Factor” Classes. Similarly, the “Real Binary Data Interpretation” Class specializes the “Numerical Binary Data Interpretation” Class for the interpretation of sequences representing float numbers. In particular, for float numbers expressed in fixed point format, we have defined the “Fixed Point Binary Data Interpretation” Class, which specializes the “Real Binary Data Interpretation” Class. On the right branch of the hierarchy, the “Tabular Binary Interpretation” Class specializes the “Binary Data Item Interpretation” Class, for defining interpretations that depend on the binary values. A textual example of tabular interpretation is binary sequences from “0000” to “1010” must be interpreted as unsigned decimal number, and binary sequences from “1010” must be interpreted as signed decimal number. The “Tabular Binary Interpretation” Class has thus been associated with the “Range” Class, which is characterized by the “binary values” and “interpretation values” attributes. Next, we have specialized the “Tabular Binary Interpretation” Class into the “String Tabular Binary Interpretation” and “Numerical Tabular Binary Interpretation” Classes, to respectively describe string-based or numerical-based interpretation of binary values. The “Numerical Tabular Binary Interpretation” Class also constrains the “Range” Class to the “Binary Numerical Range” Class, which has been introduced to consider numerical features such as the ones related to the “Shift Factor” and “Scale Factor” Classes.

Logical binary structure level

At this level, the metamodel defines the Classes for the specification of logical binary sequences representing level 4 binary sequences. Central to this level are the Classes defined by the Class Diagram in Fig. 27.

Fig. 27

Definition of the “Logical Binary Message Structure” Class—structure composition

In particular, this diagram shows the following Classes: “Logical Binary Message Structure,” “Logical Binary Frame Structure,” “Logical Binary Subframe Structure,” and “Logical Binary Page Structure.” The “Logical Binary Message Structure” Class identifies the message structure at this level. This Class is associated with the “Sequence of Logical Bits Structure” Class via the “start sequence” and “end sequence” attributes, which indicate that the data sequences are delimited by these two sequences, respectively. The “Logical Binary Message Structure” Class is also associated with the “Logical Binary Frame Structure” Class, which is for the specification of the frames composing the message. Similarly, frame sequences can be delimited by start and end sequences, as indicated by the definition of the homonym relationships between the “Logical Binary Frame Structure” Class and the “Sequence of Logical Bits Structure” Class. In addition to this, the “Logical Binary Frame Structure” Class is associated with the “Logical Binary Subframe Structure” Class to indicate that a frame aggregates subframes. The “Logical Binary Subframe Structure” Class can also be defined in terms of other subframes presenting identical structure, as shown by the “has identical structure of” relationship. Moreover, this Class is also associated with the “Logical Binary Page Structure” Class, which can be used to defined the message pages in terms of “sequence of Logical Bits Structure” Classes. Similarly to the other Classes in the diagram, the “Logical Binary Page Structure” Class can be delimited by start and end sequences, as shown by the homonym relationships. Finally, the “Logical Binary Page Structure” is associated with one or more “Sequence of Logical Bits Structure” Classes, which define the content of the page.

With the objective of promoting unambiguous specifications, the “Logical Binary Message Structure,” “Logical Binary Frame Structure,” “Logical Binary Subframe Structure,” and “Logical Binary Page Structure” Classes can be associated with Classes for the semantic and pragmatic definitions. As shown by the Class Diagram in Fig. 28, the “Logical Binary Message Structure” is associated with the “Logical Binary Message Semantics” and the “Logical Binary Message Pragmatics” Classes, and so on. Moreover, with the objective of supporting a uniform computer processing of ICML-based specifications, the above “structure” Classes have also been defined as specialization of the “Sequence of Logical Bits Structure” Class.

Fig. 28

Definition of the “Logical Binary Message Structure” Class—semantic and pragmatic descriptions

The level specification concludes with the definition of the “Sequence of Logical Bits Structure” Class. As shown by the Class Diagram in Fig. 29, this Class is a specialization of the “Sequence of Bits Structure” Class and is associated with the “Group,” “Sequence of Logical Bits Semantics,” “Sequence of Logical Bits Pragmatics,” and “Binary Data Item Structure” Classes. The “Group” Class defines aggregation of sequences for specific purposes, for example, all the sequences representing the parameters of the ephemeris. The “Group” Class can be hierarchically composed of other “Group” Classes, as shown by the inheritance relationship with the “Subgroup” Class. The “Group” Class is also associated with the “Group Semantics” and the “Group Pragmatics” Classes. Similarly, the “Sequence of Logical Bits Semantics” and the “Sequence of Logical Bits Pragmatics” Classes similarly support the description of the “Sequence of Logical Bits Structure” Class. Finally, the “Binary Data Item Structure” Class is the above level Class and is associated with the “Sequence of Logical Bits Structure” for traceability purposes.

Fig. 29

Definition of the “Sequence of Logical Bits Structure” Class

Physical binary data

At this level, the metamodel defines the Classes for the specification of the physical binary sequences, that is, the actual sequences of bits transmitted. As shown by the Class Diagram in Fig. 30, the metamodel defines the “Physical Binary Message Structure” and “Data Block” Classes.

Fig. 30

Definition of the “Physical Binary Message Structure” Class

The “Physical Binary Message Structure” Class is associated with the “Sequence of Physical Bits Structure” for the specification of the start and end sequences delimiting each data sequence. The data sequences can be specified using the “Data Block” Class, which specializes the “Sequence of Physical Bits Structure” Class. The “Data Block” Class is also associated with the “Sequence of Physical Bits Structure” Class to define three subsequences: “block interleaver start”—preceding the data; “data”—containing the data; and “block interleaver end”—concluding the block.

Physical signal level

At this level, the metamodel defines the Classes for the specification of the analog signal representing sequences of physical bits. The Classes cover the specification of the signal physical properties and of the mapping between these properties and physical binary sequences. The signal properties can be represented using the “Signal Structure” Class, which is defined by the Class Diagram in Fig. 31.

Fig. 31

Definition of the “Signal Structure” Class

The “Signal Structure” Class is associated with the “Control Signal Structure” and the “Data Signal Structure” Classes. The “Control Signal Structure” Class represents the physical properties of the signals supporting the data communication, such as the carrier or synchronization signals. These signals are periodic and are represented using the “Period Signal” Class, which is defined by the Class Diagram in Fig. 32.

Fig. 32

Definition of the “Periodic Signal” Class

In particular, the “Periodic Signal” Class is associated with the “Phase,” “Amplitude,” and “Frequency” Classes. The “Phase” Class, which represents the homonym property, is associated with the “Double” and “SysML Angle Unit” Classes. The former is used to indicate the phase value, and the latter indicates the measurement unit.

The “Data Signal Structure” Class represents the physical properties of the signal conveying level 2 binary data. As shown by the Class Diagram in Fig. 33, this Class is associated with the “Frequency Band” Class, which in turn is associated with the “Frequency,” “Phase Range,” “Amplitude Range,” and “Phase—Amplitude Combination” Classes. The “Frequency” Class, which represents the homonym property, indicates the upper and lower bound limits of the “Frequency Band” Class. The “Phase Range” Class, which represents the admissible phase values, is associated with the “Phase” Class via the “upper bound” and “lower bound” relationships. The “Phase” Class is also associated with the “SysML Angle Unit” Class for the specification of the measurement unit. Analogously, the “Amplitude Range” Class, which represents the admissible amplitude values, is associated with the “Amplitude” Class via the “upper bound” and “lower bound” relationships. The “Amplitude” Class is also associated with the “SysML Electrical Unit” Class for the specification of the measurement unit. Finally, the “Phase—Amplitude Combination” Class defines the admissible subset of the Cartesian product between the defined “Phase Range” and “Amplitude Range” Classes.

Fig. 33

Definition of the “Data Signal Structure” Class

The metamodel concludes with the definition of the “Signal Combination” Class for the specification of the mapping between values of the signal properties and of the physical binary sequences. As shown by the Class Diagram in Fig. 34, this Class is associated with the “Sequence of Physical Bits Value” Class—describing the binary coding, and the “Amplitude Range,” “Phase,” “Frequency Band,” Classes—describing the signal properties.

Fig. 34

Definition of the “Signal Combination” Class

This definition concludes the specification of the ICML Structure metamodel. Currently, the ICML language does not introduce any explicit specialization of the BPMN language for representing the conversion processes, and therefore, the ICML Implementation metamodel coincides with the BPMD metamodel.