For the complete story, including figures, graphs, and images, please download the PDF of the article, above.
Galileo receiver designers require formal interface specifications for the Galileo signal-in-space (SIS) in order to write unambiguous and accurate specifications for Galileo receivers. To compute their positions, Galileo receivers must be able to retrieve timing and orbital information from the data stream conveyed in Galileo analog signals.
For the complete story, including figures, graphs, and images, please download the PDF of the article, above.
Galileo receiver designers require formal interface specifications for the Galileo signal-in-space (SIS) in order to write unambiguous and accurate specifications for Galileo receivers. To compute their positions, Galileo receivers must be able to retrieve timing and orbital information from the data stream conveyed in Galileo analog signals.
Next to the algorithms and the numerical issues, the correctness of the position solution also depends on the semantically correct interpretation of the data items in terms of their syntax and semantics. Multi-GNSS receivers are particularly challenged as these combine data from multiple and diverse formats in order to calculate the position solutions.
For example, an orbital eccentricity parameter can be represented in several binary and numerical formats. In order to reduce possible misunderstandings between Galileo designers and designers of other types of GNSS receivers, and also to minimize the risk of incorrectly computing a position solution, the Galileo interface specification must be clear, with all ambiguities and inconsistencies eliminated.
Misinterpretation of design specifications is not a new problem in the wider field of engineering. In the system engineering community, these problems are addressed by formalized approaches such as Model-based System Engineering (MBSE), which require design documents to use formal and graphical languages.
The intent of an MBSE approach is to overcome the inherent ambiguities of natural language-based specification documents. MSBE approaches are used not only to support design specifications, but also to support all the phases of system design and life cycle, including intermediate verifications and final system validation.
In this article, we aim to overcome the limitations of the current GNSS SIS interface specification by proposing an MBSE approach for the Galileo SIS Interface Control Document (ICD), which is currently available in a textual format.
To overcome the limitations of the current GNSS SIS interface specifications, we propose use of the Interface Communication Modelling Language (ICML), a modelling language that enables GNSS designers to formally and graphically specify SIS interfaces, as an alternative to the conventional text used to prepare ICDs.
As a consequence of the increased level of formality, we expect to see an improvement in the design processes of GNSS-based systems, including enhanced communication among stakeholders, reduced design times, and reduced design risks.
In addition, ICML can also lead to the automatic generation of software conversion routines; specification consistency and completeness checking to ensure the correctness of the interface specifications and their consistency with lower-level design specifications; generation of designer friendly and interactive documentation in various formats, including web-based ones; and multi-GNSS interoperability on the receiver side.
An important note: Although no plans have been made to release the Galileo ICD using ICML, in this study we evaluate ICML features that could be particularly valuable for Galileo.
ICML is based on the standard and widely known Unified Modelling Language (UML) and Business Process (BP). This allows us to leverage existing UML and BP modelling tools, thereby gaining advantages from their wide availability and related standards. These system engineering tools also include Object Constraint Language (OCL) for specifying constraints on models, and SysML, system modelling language.
In this article, we first will outline the concepts of MBSE and UML and discuss the advantages that Galileo would obtain from a formal SIS specification in ICML. We then examine the structure of ICML specifications and provide an example ICML specification for a simplified and facsimile Galileo F/NAV message, which is the designated navigation message format for the Open Service on the E5a frequency.
Model-Based System Engineering (MBSE)
Traditionally, the design of a complex system relies on a system engineering process that uses on text documents and engineering data in multiple formats from different disciplines. This information is generally developed and shared electronically among all the relevant system stakeholders.
Much of the system engineering effort is spent to ensure that information is consistent across disciplines and maintained throughout the various versions of the document produced while advancing the system design. To assist in this, a system engineering management plan (SEMP) document specifies how the entire engineering process develops, including which documents need to be produced and what their inter-relationships are.
Due to its inherent nature, the document-based approach presents fundamental limitations, deriving from manual operation of support activities, dispersed data, and unstructured representation of information. Jointly, these factors affect the traceability of requirements across documents and throughout the design process — affecting design specification consistency and completeness, and thus representing a source of risk for development of the system.
All these problems are further exacerbated when the system under design involves integration of two or more systems, especially in cases where the systems are independently designed. In addition to increased engineering complexity due to the larger number of systems, the communication interfaces become a critical aspect of the entire process.
INCOSE, the International Council on System Engineering, defines MBSE as “the formalized application of modelling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle.”
As such, MBSE aims to overcome the limitations of the conventional document-based approach by leveraging computing tools to structure, share and automatically analyse design information. The ultimate purpose is to ensure specification completeness and consistency, traceability of requirements and design choices, reuse of design patterns and specifications, and a shared understanding of the designs among users and designers.
As a result, the application of MBSE obtains several advantages, presented here with examples of the benefits:
- Enhanced communications: Enabling a shared understanding of the system across the development team and with other stakeholders, and the ability to integrate views of the system from multiple perspectives.
- Reduced development risk: Providing requirements validation and design verification throughout the process, as well as more accurate cost estimates to develop the system.
- Improved quality: Providing more complete, unambiguous and verifiable requirements; more rigorous traceability between requirements, design, analysis and testing; enhanced design integrity.
- Increased productivity: Analyzing the effects of requirements and design changes more quickly, reusing existing models to support design evolution, reducing errors and time spent on integration and testing, and automating document generation.
- Enhanced knowledge transfer: Standardizing specification and design information so that it can be accessed via query and retrieval software.
MBSE achieves these advantages by building a system model and model repository. A system model is represented digitally and can include information about the system’s specification, design, analysis, and verification.
The model can be produced using a software tool qualitative metrics need to be satisfied by the model for the specific design study, such as model fidelity, model breadth, and model depth. A model repository provides a database of model blocks that can be shared among all the actors involved in the system design, across all the design and development phases.
The software industry has always been at the forefront of the modelling languages, information processing tools and technologies. As a natural consequence, MBSE currently takes advantage of the available modelling languages including UML, BP, and associated tools such as Magic Draw or System Architect along with technologies (e.g., XML), which originated in the software domain and were eventually tailored to the needs of system engineering.
Unified Modelling Language
In this section we outline the basic concept of UML upon which ICML is defined.
UML is a standard graphical modelling language for the representation of structural and behavioural aspects of systems, using the concept of objects. The language consists of a set of diagrams, each defining a set of palettes and a set of relationships that can be used to relate the palettes.
For example, a diagram for the representation of structural aspects is the class diagram. This type of diagram is used to describe classes, or types of objects, in terms of properties and relationships, for general conceptual and detailed modelling.
. . .
ICML Benefits for the Galileo SIS Interface Specification
The Galileo SIS ICD will be used by a large number and variety of receiver designers responsible for defining the specification of Galileo user equipment. New receiver designs may need to reuse and/or modify existing GNSS hardware and software design specifications to conform to Galileo ICD, or solve interoperability issues in existing receivers that use GNSSes.
. . .
ICML Specification
ICML covers both the structural and the implementation aspects of GNSS SIS interface specifications. The structural aspects concern the definition of the data structures. The implementation aspects concern how data values are dealt with.
. . .
Data definition covers the specification of the logical structure of the message data…
The binary coding level covers the specification of the binary data item structures and coding…
Logical binary structure specifies the aggregation of binary sequences in terms of frames, sub-frames, and pages…
The physical binary coding level specifies the partitioning structure for binary sequence segments resulting from digital modulation…
Finally, the physical signal level specifies the structure of analog signals…
. . .
Example Specification for Galileo F/NAV
We will now present a simplified and facsimile Galileo SIS interface specification for the F/NAV message as an example of MBSE applied to GNSS ICDs. For the sake of conciseness, we will illustrate only the ICML specification for the logical binary data and physical binary data levels.
We assume that at the data definition level, the following data items are defined: OMEGADOT and Eccentricity e, as application data, and Page Type Field and CRC (cyclic redundancy check) as control data. The binary coding of these data items can be specified within ICML Level 4, which will also provide the basis for the Level 3 definition of logical binary representation. This representation concerns how Level 4 sequences are combined to form the binary message, including the binary control sequences for start, end, and synchronization.
. . .
Conclusions
Galileo will bring considerable advantages to navigation systems using GNSS, and to the Galileo civilian community, providing independence, increased accuracy, integrity and reliability. Promoting the use of Galileo signals means Galileo receiver designers must be able to accurately specify the Galileo receivers design, derived from the interface with the Galileo SIS.
Specifically, Galileo designers must eliminate Galileo ICD ambiguities and inconsistencies in order to reduce risk, thus making the design and development of Galileo receivers more cost- and time-efficient.
ICML brings a model-based system engineering approach into the specification of GNSS SIS interfaces, thus obtaining numerous advantages, including enhanced communication and reduced design risks. The approach supports a wide number of automatic exploitations (such as checking specification completeness and consistency, document generation, and so forth).
ICML may also be used to identify multi-GNSS interoperability issues on the receiver side involving the retrieval, interpretation, and combination of orbital and timing data from multiple GNSSes for the positioning computation.
Because ICML is based on the UML and BP standard modelling languages originated from the software community, ICML specifications can be created using the plethora of available software tools.
A final caveat: this article represents a preliminary case of study on the suitability of such an approach for the Galileo SIS interface specification and no endorsement is made on the adoption of ICML for Galileo interface.
For the complete story, including figures, graphs, and images, please download the PDF of the article, above.
Acknowledgements
The authors would like to express their sincere appreciation to Serge Valera of the EGSE and Ground Systems Section, European Space Agency, for his insightful comments.
References
[1] Eriksson, H. E., and M. Penker, B. Lyons, and D. Fado UML 2 Toolkit, Wiley, 2008
[2] Galileo OS SIS ICD Issue 1 Revision 1, September 2010, retrieved from http://ec.europa.eu/enterprise/policies/satnav/galileo/open-service/index_en.htm
[3] Gianni D., and J. Lewis-Bowen, N. Lindman, and J. Fuchs, “Modelling Methodologies in Support of Complex Systems of Systems Design and Integration: Example Applications”, Proceedings of the 4th International Workshop on System & Concurrent Engineering for Space Applications (SECESA2010), Lausanne, Switzerland, October, 2010
[4] Kossiakoff, A., and W. N. Sweet, Systems Engineering Principles and Practice, John Wiley, 2003.
[5] MoDAF Detailed Guidance, http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/ModafDetailedGuidance.htm (last accessed October 2010).
[6] “Model-Based Systems Engineering,” The Journal of the National Council on Systems Engineering (INCOSE), Volume 1, Number 1, 1994, pages 83-92
[7] Object Management Group (OMG) Business Process Model Notation Standard Specification, http://www.omg.org/spec/BPMN
[8] OMG Object Constraint Language Specification, <http://www.omg.org/technology/documents /formal/ocl.htm>
[9] OMG SysML Annex C, Model Library for Quantities, Units, Dimensions and Values (QUDV) www.sysml.org/docs/specs/OMGSysML-v1.2-10-06-02.pdf
[10] OMG SysML Specification, http://www.sysml.org
[11] OMG Unified Modelling Language Standard Specification, http://www.uml.org
[12] OMG XML Metadata Interchange (XMI) Standard Specification, http://www.omg.org/spec/XMI
[13] W3C Extensible Markup Language Specification, http://www.w3.org/XML
