Unified Message Model for Heterogeneous Serial Data Exchange Protocols

Unified Message Model for Heterogeneous Serial Data Exchange Protocols Viktor Sinitsyn1* and Florian Holzapfel1

arXiv:2608.17642v1 [cs.SE] 18 Aug 2026

1*

Institute of Flight System Dynamics, Technical University of Munich, Munich, Germany. *Corresponding author(s). E-mail(s): viktor.sinitsyn@tum.de; Contributing authors: florian.holzapfel@tum.de; Abstract Modern embedded systems are becoming increasingly complex and typically integrate numerous heterogeneous devices, such as controllers, sensors, actuators, and supporting subsystems. As a result, their development and integration involve a wide variety of serial communication protocols, ranging from standardized solutions to partially standardized and fully project-defined formats. Efficient development of such systems increasingly depends on automation toolchains, which in turn require a clear, unified, and machine-processable formal basis. This paper proposes a unified, protocol-agnostic message model for explicit and deterministic description of serial messages. The model is based on formal definition of data types, atomic message elements (containers), and complete message structure. In addition to the model itself, the paper introduces methods for practical work with it, including configurable message types for expressing structural constraints and supporting deterministic automation, as well as configurable user representations for engineering-oriented reading and editing. The proposed model and methods are demonstrated through implementation in an industrial tool environment. The results show that the approach can support machine-readable interface control document development, automated generation of transport-layer software, and practical engineering work with both standardized and weakly formalized serial protocols. Taken together, the proposed model, methods, and tool implementation provide a practical foundation for automation toolchains in heterogeneous serial communication development. Keywords: protocol-agnostic message model, serial communication, embedded systems, automation toolchains, transport-layer software generation, interface control documents, model-based systems engineering

1

1 Introduction 1.1 Heterogeneous Serial Protocols in Embedded Systems Modern embedded electronic systems are becoming increasingly complex and increasingly distributed. Instead of a small number of tightly integrated components, they often consist of many interacting devices, sensors, controllers, and supporting subsystems [1, 2]. As a result, system integration and development are becoming more difficult as well [3]. Historically, such challenges were most typical of large aerospace systems. Today, similar development burden can also be observed in rapidly developing unmanned aerial vehicle (UAV) platforms, air taxis, and other highly automated embedded systems [1]. Integration activities of such systems typically require the use of diverse serial communication protocols. These range from strictly standardized solutions, such as ARINC 429 or CAN, to fully project-defined formats implemented over generic serial interfaces such as universal asynchronous receiver-transmitter (UART).

1.2 Engineering Problem and Practical Motivation One of the most labor-intensive engineering problems in heterogeneous systems integration is interface development, which largely consists of repeated transformation of the same interface information from one representation into another. Source interface descriptions received from equipment vendors in vendor-specific formats must be reworked into interface control documents (ICDs) and then further transformed into transport-layer software (TL SW) that encodes engineering values into protocol byte streams and decodes protocol byte streams back into engineering values used by applications. In practice, this transformation is performed repeatedly for redundant channels of onboard equipment and supporting environments such as hardwarein-the-loop test rigs, flight test instrumentation (FTI), and laboratory analyzers [3–7]. Repeated manual processing of the same ICD data, whether through conversion of human-readable document formats or through manual development of TL SW source code, results in substantial engineering effort and multiple human-induced errors [7, 8]. For this reason, efficient practical development relies on automation toolchains used for the generation of TL SW and, where needed, corresponding human-readable ICDs [1, 3–5]. Similar tool-supported and model-based system engineering (MBSE) approaches have long been pursued in large aerospace companies and safety-critical development environments [4, 9–12]. A necessary core element of such a toolchain is a formalized machine-readable ICD format that can serve as a common source for downstream engineering artifacts [4–6, 13]. A classical way to define such an ICD is to represent it as a collection of protocol-specific parts such as CAN [14], Ethernet [15–17], or ARINC 429 [18]. However, this approach has several important limitations.

2

• It cannot be applied as is to protocols for which no accepted message standard exists. In such cases, a new protocol-specific part must be developed for each new protocol type. • It cannot adequately cover practical implementations that deviate from the standard in specific parts, such as CAN-based messages with little-endian payload encoding, without additional effort to adapt the toolchain. • It leads to unnecessary implementation overhead, because supporting tools must maintain separate processing branches for different protocol families and repeatedly adapt them to deviations from standards encountered in practice. • It provides no unified basis for automation across heterogeneous communication environments. In practice, different protocol families require different description mechanisms and tools, which substantially increases toolchain development and maintenance effort within a single project. For this reason, machine-readable ICD and automated TL SW development would benefit from a unified, protocol-agnostic message model capable of describing arbitrary message formats within a single common framework.

1.3 Existing Description Approaches and Their Limitations Several established approaches exist for describing communication interfaces and message formats. In the automotive domain, AUTOSAR [19] defines interface descriptions through ARXML tightly integrated with its architectural framework. For CAN-based systems, DBC [20] files are widely used to describe signal layouts within frames. Formal description languages such as ASN.1 [21] provide standardized mechanisms for defining message structures and encoding rules and are extensively applied in telecommunications and related domains. Despite their usefulness, these approaches do not close the gap between standardized message specification mechanisms and the practical needs of heterogeneous embedded system integration. Existing solutions typically exhibit one or more of the following characteristics: • tight coupling to a particular ecosystem or architectural framework, as in AUTOSAR-based interface descriptions; • addressing only a specific protocol family, as in CAN-oriented DBC definitions; • implicit reliance on assumptions inherited from a particular standard or modeling approach, for example specifying a message identifier value without explicitly defining how and where that identifier is encoded in the transmitted message; • assumptions of predefined encoding grammar optimized for telecommunications standards, as in ASN.1. As a result, heterogeneous protocol sets within a single engineering project are still typically handled by combining multiple protocol-specific description approaches. In practice, embedded system developers frequently encounter a mixture of partially standardized and fully custom serial message formats that must be implemented across onboard software, redundant channels, and multiple supporting environments. Under such conditions, no commonly adopted protocol-agnostic message meta-model exists that: 3

• uniformly describes arbitrary serial message structures across heterogeneous protocols; • explicitly captures low-level encoding semantics required for implementation; • serves simultaneously as a machine-processable source for automated code generation and as a structured basis for system-level interface management.

1.4 Special Case of Weakly Formalized Protocols This limitation becomes especially critical for weakly formalized protocols. For communication types such as ARINC 429, CAN, ARINC 825 [22], MAVLink [23] or UDP/IP, at least a formalized frame and header structure exists and can serve as a reference for interface description. In contrast, UART-based and similar project-defined serial formats often have no commonly adopted formal message description approach at all. Message sizes, endianness, encoding rules, and addressing conventions are then defined descriptively in human-readable documents on a project-specific basis. For such protocols, the absence of a unified description method makes systematic automation particularly difficult. In these cases, a unified message model is not merely a way to simplify existing practice, but a necessary basis for introducing a consistent and machine-processable description at all.

1.5 Contribution of This Paper This paper addresses the problem described through three complementary contributions. First, it introduces a unified, protocol-agnostic meta-model for describing serial message structures in an explicit and machine-processable form. The model is intended to support arbitrary message formats across heterogeneous communication environments. Second, the paper introduces methods for working with this model in practice. These methods include mechanisms for defining structural constraints, supporting deterministic automation, and providing configurable engineering-oriented representations of the same underlying message description. In this way, the work addresses not only the problem of formal representation, but also the problem of efficient use of such a representation in real development workflows. Third, the proposed concepts are applied in an industrial MBSE tool, providing a reference implementation of the model and methods. Taken together, these contributions establish all three major elements of a modelbased systems engineering (MBSE) approach: model, methods, and tool support.

1.6 Structure of the Paper The remainder of the paper is organized as follows. Section 2 introduces the terminology used throughout the paper. Section 3 reviews the state of the art, including existing standards and related approaches to interface and message description. Section 4 presents the proposed unified message model. Section 5 introduces the methods for working with this model in practice, including mechanisms for structural constraints, automation, and configurable user representations. Section 6 presents the 4

reference implementation and demonstrates its application in practical engineering workflows. Finally, Section 7 summarizes the results.

2 Terminology This section introduces several terms used throughout the paper to describe the structure of serial communication messages. Table 1: Terminology used in the paper Term

Description

Container

A container is a structural component of a message that encapsulates a logically related portion of the message data. Containers may represent message identifiers, payload elements, length fields, checksums, or other structural elements. A container role denotes the functional purpose of a container within a message structure, such as payload, identifier, length, checksum, or other. A data type defines the set of possible values of a message element and the basic rules of their encoded representation and interpretation. In the proposed model, data types serve as the basic encoding units referenced by message containers. Decoding is the process of extracting and interpreting encoded message contents in order to reconstruct engineering-level values. Encoding is the process of transforming engineering-level values into their encoded representation within a message according to the applicable encoding rules. Encoding semantics denotes the set of properties that define how the value of a message element is encoded and interpreted, including aspects such as data type, bit length, signedness, sign encoding, byte order, bit order, resolution, and offset. An Embedded system is a computer-based technical system designed to perform dedicated operational functions within a larger physical system and typically integrating computing devices, sensors, actuators, and communication interfaces. A representative example is onboard aircraft equipment, including UAV platforms. Heterogeneous serial protocols are serial communication protocols that are based on different underlying communication standards or project-specific conventions and therefore differ in frame structure, header organization, identifier representation, encoding semantics, and payload layout. In the context of this paper, the term emphasizes that a unified message model must be applicable across such structurally different protocols within one common framework. An identifier is a container role that is used to distinguish a message type or message instance within a communication channel.

Container role

Data type

Decoding Encoding

Encoding semantics

Embedded System

Heterogeneous Serial Protocols

Identifier

5

Table 1: Terminology used in the paper (continued) Term

Description

Message

A message is a unit of data transmitted as a single communication frame or packet over a serial interface. A message consists of a sequence of structured data elements that collectively represent a specific data exchange instance between communicating systems. A message model is a structured representation of a complete message, combining message-level properties with a set of containers that together define its full encoded form. Message structure describes the ordered arrangement of containers that together form a complete message. A message type is a formal description of allowable characteristics and structural constraints for a class of messages within a given communication domain. Payload refers to the portion of a message that carries applicationlevel data intended for consumption by the receiving system. The term can also refer to the role of containers carrying such data. Serial protocols are digital communication protocols in which information is transmitted as an ordered sequence of bits or bytes over a communication channel according to defined structural and encoding rules. Transport-layer software is software responsible for encoding engineering values into protocol byte streams and decoding protocol byte streams back into engineering values used by applications. A user representation is a configurable engineering-oriented view of the underlying formal message model, intended for convenient reading, editing, and practical use.

Message model

Message structure Message type

Payload

Serial Protocols

Transport-layer software User representation

3 State-of-the-Art This section reviews the state of the art relevant to the present work in three steps. Section 3.1 considers communication standards that define message transmission and, to different degrees, message structure. Section 3.2 reviews standards and formats intended for interface description and automation-oriented development toolchains. Section 3.3 then considers published work addressing system complexity, MBSE-based development, automation approaches, and machine-readable handling of interface and message data. This structure is intended to position the proposed model both with respect to existing standards and with respect to related engineering methods and tools.

3.1 Serial Protocols Standards A number of communication standards already provide formalized definitions of message transmission and message structure. For the purposes of this paper, they are important not because they are insufficient in some absolute sense, but because together they illustrate the variety of communication formats that a unified message model should be able to describe within one common framework. 6

3.1.1 ARINC 429 ARINC 429 [18] is a highly formalized avionics communication standard. It defines electrical characteristics, timing, word structure, and protocol rules for 32-bit words transmitted over the bus. It therefore represents a communication format with a strongly constrained and explicit message structure. From the perspective of the present work, ARINC 429 is important as an example of a standard whose message definition is already highly formalized and can be represented in a unified way.

3.1.2 CAN Classic CAN [14] standardizes frame structure, identifiers, control fields, data fields, and error handling, which makes it a strong example of a protocol family with a clearly defined message format. In the context of this paper, CAN is important not only as a standardized protocol in its own right, but also as a basis for widely used higher-level development ecosystems.

3.1.3 ARINC 825 ARINC 825 [22] is an airborne communication standard built on CAN. It uses the CAN extended frame format as its communication basis, while introducing additional aerospace-specific conventions and constraints. This makes ARINC 825 especially relevant to the present work: although it shares the same underlying frame basis with CAN EFF, its engineering interpretation and usage constraints differ. A unified message model should therefore be able to represent both the shared structural basis and the domain-specific differences built on top of it.

3.1.4 Ethernet, IP, and UDP These standards [15–17] form a widely used communication stack. Ethernet provides link-layer framing and addressing, IP defines packet addressing and forwarding at the network layer, and UDP defines a lightweight transport-layer header and datagram mechanism. At the same time, this stack mainly standardizes communication headers and transmission-layer conventions, while the application-level payload structure remains outside its scope. For the present work, this stack is therefore important as an example of a communication environment in which lower communication layers are standardized, while the engineering content of transmitted messages still requires an additional explicit description model.

3.1.5 UART Universal asynchronous receiver-transmitter differs from the standards above in that it defines only a serial transmission mechanism with byte framing and related low-level communication parameters. It does not define application-level message structure. In practice, message boundaries, field ordering, endianness, integrity checks, and payload interpretation are usually specified on a device or project-specific basis. For this reason, UART-based formats are one of the clearest examples of communication environments for which a unified transport-layer message model is especially valuable. 7

3.1.6 MAVLink MAVLink [23] is a binary telemetry protocol used in unmanned and robotic systems to provide a standardized message structure over otherwise simple communication links like UART or UDP payload. Its role is not to define the underlying physical transport, but to organize application-level message exchange within a specific domain in a consistent and interoperable way. In the context of the present work, it is relevant as an example of a domain-specific attempt to standardize the structure of otherwise weakly formalized serial messages.

3.1.7 Summary Taken together, these standards demonstrate that communication environments may differ substantially in scope, level of formalization, and layer coverage. Some define message structure in detail, some define only headers or transport mechanisms, and some leave most message semantics to project-specific conventions. The objective of the proposed work is therefore not to replace these standards, but to provide a unified message model capable of describing all such cases within one explicit and machine-processable framework.

3.2 Description Formats and Toolchain-Oriented Standards In addition to communication standards themselves, a number of established formats and frameworks are used to describe communication interfaces and support engineering automation.

3.2.1 AUTOSAR AUTOSAR [19] is not a communication protocol standard, but a comprehensive framework and toolchain-oriented architecture for automotive electronic control unit (ECU) development. Official AUTOSAR documentation describes it as an architecture for automotive ECUs connected to networks such as CAN [14], LIN [24], FlexRay [25], and Ethernet [15–17]. In this sense, AUTOSAR is a strong positive example: it provides exactly the kind of tool-supported development environment that is needed in complex projects. However, its applicability is tied to the AUTOSAR ecosystem, its architectural concepts, and its target domain. It is therefore not a protocol-agnostic basis for describing arbitrary serial message structures such as UART-based custom formats or avionics standards such as ARINC 429.

3.2.2 DBC DBC [20] is a simple and widely used format for describing CAN communication. In practice, it is effective for defining CAN frame layouts and decoding rules and is supported by established industrial tools. For CAN-oriented projects, this makes DBC a practical and successful solution. At the same time, it remains tied to the CAN representation paradigm and does not provide a unified description basis beyond that domain.

8

3.2.3 FIBEX The FIBEX [26] standard extends this idea toward broader automotive network description. ASAM defines FIBEX as a uniform XML-based interface description for configuring automotive network software, with extensions for CAN, LIN, FlexRay, and Ethernet. This makes FIBEX broader than DBC and highly relevant for multinetwork automotive environments. However, it is still oriented toward a particular engineering ecosystem, a limited set of underlying protocols, and an associated set of implicit assumptions, rather than toward a general protocol-agnostic model for arbitrary heterogeneous serial communication formats.

3.2.4 LIN Configuration Language (LDF) LDF [27] is another example of a useful but protocol-specific description approach. It provides a formal way to describe LIN networks and their configuration. This is valuable within the LIN domain, but it does not generalize into a universal basis for heterogeneous message description across unrelated protocol families.

3.2.5 Summary Taken together, these formats and frameworks show that powerful automationoriented solutions already exist and are successful within their intended domains. The purpose of the present work is not to replace them, but to provide a unified message model that can serve as a common basis across heterogeneous communication environments, including cases that fall outside the scope of domain-specific toolchain standards and protocol-specific description formats.

3.3 Related Work The reviewed literature consistently indicates that modern embedded and avionics systems are becoming increasingly complex and increasingly difficult to develop efficiently. This complexity is associated not only with the growing number of integrated functions and devices, but also with the increasing number of engineering artifacts, configuration parameters, interfaces, and development dependencies that must remain mutually consistent throughout the process [1, 2, 7]. In such projects, development effort is determined not only by the size of the system, but also by the diversity of artifacts and by the need to preserve consistency across multiple stakeholders, tools, and development stages. To cope with this complexity, many authors propose model-based systems engineering (MBSE) and related digital-development approaches. In this line of work, models are treated as the central formal basis for organizing development information, improving traceability, and reducing inconsistencies between engineering artifacts [3, 9, 12, 28]. Such approaches are used to support early design activities, architectural refinement, validation planning, and communication between different engineering domains. In this sense, MBSE provides an important general framework for managing complexity, but by itself it does not yet guarantee efficient development.

9

For this reason, a number of authors go further and propose automation-oriented methods and toolchains. Halle and Thielecke describe AvioNET as a highly automated digital process framework for avionics platform development, emphasizing data continuity and interconnection of engineering activities [9]. Brahmi et al. propose a formalized and automation-oriented software-engineering process for avionics, with the goal of improving safety and efficiency of development [4, 10]. Mueller et al. introduce a dedicated platform level for IMA systems development with extensive automation tool support [3]. Panchal et al. describe a process-oriented build tool for airborne safety-critical software development [11]. Hochstrasser proposes a modular model-based development approach for safety-critical flight-control software [12]. Rhein et al. introduce a holistic interface-database approach in which communication data are stored in a central machine-readable form and transformed for downstream engineering tasks such as integration and test-bench development [5]. Chrysalidis and Thielecke propose UCoF as a single-source-of-truth configuration format for virtual, hybrid, and hardware-based testing environments, with emphasis on configuration reuse and multi-fidelity development rather than on detailed formalization of message structure itself [6]. Annighoefer et al. also describe automation-oriented platform modeling approaches in which ICDs and network-message-related artifacts are generated from a shared formal engineering basis [29]. Taken together, these works show that MBSE becomes practically effective only when complemented by explicit automation mechanisms, shared machine-readable artifacts, and tool support for transformation and consistency maintenance. At the same time, the reviewed work also shows that the question of how message data themselves should be represented and processed in a machine-readable form remains insufficiently addressed. Most automation-oriented approaches focus on architecture, platform configuration, validation workflows, or interface databases as broader engineering constructs. Comparatively close exceptions are the works of Watkins et al., which include explicit data-message modeling in the eSAM approach, but the presented solution is tied to ARINC 429-oriented representation and does not directly generalize across heterogeneous protocol families without introducing additional protocol-specific modeling branches [30, 31]. Thus, although the literature clearly demonstrates the value of MBSE and development automation, it still lacks a unified message model intended specifically for explicit and machine-processable description of heterogeneous transport-layer message structures. Such a model would not only address the problem considered in the present paper, but would also strengthen the automation-oriented approaches proposed in the works reviewed above.

4 Message Model Proposal 4.1 Scope and Problem Statement The objective of the proposed model is to provide a unified representation of message formats used in heterogeneous serial communication environments. The focus of this work is limited to the structural description of transmitted messages. Low-level transmission mechanisms—such as bit stuffing in CAN or byte framing conventions in UART interfaces (e.g., 8-N-1)—are outside the scope of the proposed 10

model. Likewise, the model does not address higher-level communication procedures such as handshake protocols, session management, or transport-level exchanges (e.g., TCP connection handling). These aspects are assumed to be handled by lower-level transmission mechanisms or higher-level communication protocols surrounding the message structure. Instead, the proposed approach focuses exclusively on the structural definition of message contents and their encoding. The model is intended to support a wide range of serial communication technologies commonly encountered in embedded and avionics systems. Representative examples include, but are not limited to: • ARINC 429 • CAN BFF • CAN EFF • ARINC 825 • UART-based protocols like MAVLink • UDP/IP/Ethernet stack To ensure practical applicability across heterogeneous communication environments, the proposed message model approach is guided by a set of the following requirements: R1 — Protocol universality The model must be capable of representing message formats used across heterogeneous communication protocols, including both standardized and custom serial message structures. R2 — Complete message specification A complete message instance must be constructible solely from information contained in the model. The model must contain sufficient information to deterministically construct the exact binary representation of a message. No implicit structural assumptions or externally defined message elements should be required. This includes explicit representation of encoding semantics such as byte ordering, bit ordering, element positioning, and container sizes. R3 — Data representation flexibility The model must not impose artificial or standard-driven restrictions on data types, addressing schemes, or value representations used within message structures. The following subsections present the model developed to satisfy the stated requirements.

4.2 Message Model 4.2.1 General data A typical message targeted by the proposed model can be illustrated by a representative raw CAN frame waveform, as shown in Fig. 1. After removal of low-level transmission artifacts, such as start- and end-of-frame markers, inter-frame spacing, and stuff bits, the underlying message structure can be identified as shown in Fig. 2.

11

Fig. 1 CAN frame structure raw

Fig. 2 CAN frame structure

We call an atomic element of a message a container. Each container corresponds to a specific fragment of the transmitted bitstream and is associated with a particular meaning within the protocol structure, such as identifier fields, payload data, control information, or checksum. It is also important to note that, in practice, message containers may represent data in a wide variety of formats. These formats differ in size, encoding rules, numeric interpretation, and structural composition. Therefore, before introducing the full message model, it is necessary to define the categories of data types that may appear within message containers. Accordingly, the complete message model is structured into three parts, organized in a bottom-up manner: • Data Type Model • Container Model • Message Model

4.2.2 Data Type Model In the proposed approach, the set of available data types is not fixed. Users are allowed to define and extend the set of data types according to the needs of a specific project. However, all user-defined data types must belong to one of the fundamental data type groups described below: • Boolean values • Integer values • Floating-point values • Fixed-point values

12

• Binary-coded decimals (BCD) • Structured types The majority of other commonly used representations can be expressed using these groups. For example, characters can be represented as unsigned 8-bit integers, strings as structures or arrays of characters, and opaque message fragments as containers with unspecified internal structure. The model can also be easily extended to additional data type groups, for example Gray code (reflected binary code). Each data type is characterized by a set of properties describing how the corresponding value is represented in the message. These properties define both the structural layout and the interpretation of encoded values. Table 2 summarizes the properties associated with data type. Table 2 Data type properties Property

Description

Applicable groups

Name Type group Bit length

Unique identifier of the data type One of the fundamental groups listed above Number of bits occupied by the value. May be unspecified at the type level. Indicates whether the value is signed or unsigned. May be unspecified at the type level. Representation method used for signed values of integer data types (two’s complement, one’s complement, sign bit) Value represented by the least significant bit Offset applied when converting encoded values to physical quantities

all all all

Signedness Sign encoding

Resolution Offset

integer, fixed-point integer, fixed-point

fixed-point, BCD fixed-point, BCD

Not all properties are applicable to every data type group. For example, only fixed-point values require additional scaling parameters such as resolution and offset. To support flexible type reuse, some properties of a data type may remain unspecified at the data type definition level. Such properties must be explicitly defined when the type is used within a message container. For example, an integer data type may have an unspecified size. In that case, the corresponding container must not only reference the data type, but also explicitly define the size property. This ensures that the exact binary layout of the message can be deterministically derived from the model.

4.2.3 Container Model As mentioned above, a message is composed of structural elements referred to as containers. Each container represents a fragment of the transmitted message and defines how a particular piece of information is encoded within the message structure.

13

Container Roles The proposed model distinguishes several container roles according to their purpose within a message: Payload containers Payload containers carry application-level data. These containers encode engineering parameters exchanged between communicating systems. In many cases, payload containers represent the primary functional content of the message. Depending on the protocol, additional identifiers or control information may also appear within the payload. Identifier containers Identifier containers are used to distinguish message types or message instances within a communication channel. Such containers typically carry fixed values that allow receivers to recognize the message format and interpret their contents correctly. Length containers Length containers represent the total size of the transmitted message or payload fragment. These containers are required in protocols where message length is explicitly encoded as part of the transmitted frame (e.g. CAN). Checksum containers Checksum containers provide message integrity verification. Their values are calculated from other parts of the message according to a specified algorithm. Other containers Other containers represent message elements that do not fall into the categories above. In practice, such fields may include reserved areas, protocol-specific control bits, or placeholders intended for future use. Although they may not carry meaningful application data, they can still be represented to ensure accurate reconstruction of the transmitted message. Container Properties Each container is defined by a set of properties (Tab. 3 describing its role, structure, and encoding within the message. The key requirement is that the binary representation of every container must be fully and explicitly defined by the model.

4.2.4 Message Model A message is defined as a structured composition of containers arranged within a common bit-addressed space. The message model combines a set of global properties with a collection of containers that together define the complete binary representation of the transmitted data. Basic Message Properties Each message is characterized by the properties specified in Table 4: Note: In practical applications, messages are typically defined within the context of predefined message types. A message type specifies allowable structures, constraints, and required elements for a class of messages. This includes restrictions on message

14

Table 3 Properties of a container Property

Description

Name Role

Identifier of the container within the message definition Functional role of the container (payload, identifier, length, checksum, other) Absolute bit offset of the container relative to the beginning of the message Reference to the data type used to interpret container contents Byte transmission order. Can be either "Big Endian" (Motorola) or "Little Endian" (Intel) Bit transmission order. Can be either "Big Endian" (most significant bit first) or "Little Endian" (least significant bit first). It is important to note that even though bit endianness normally match byte endianness it isn’t always true. Fixed value associated with identifier containers Parameters describing protocol-specific behavior

Address Data type Byte endianness Bit endianness

Constant value Implementation attributes

Table 4 Properties of a message Property

Description

Name Length Direction Refresh rate

Unique human-readable identifier of the message Total length of the message in bits Indicates whether the message is transmitted or received Transmission frequency for periodically transmitted messages

size, container roles, and encoding rules. However, this concept doesn’t affect the message model itself. Thus, it is introduced in detail in Section 5 as part of methods to work with the message model. User-Defined Message Properties In addition to the basic message properties defined for every message, the model allows users to introduce additional properties capturing message-type-specific behavior, such as the CRC calculation method or trailing-zero truncation as used in MAVLink. To keep the description focused, this paper does not further elaborate on this mechanism. Message Structure Definition The internal structure of a message is defined as a collection of containers placed within the message bit space. Each container occupies a specific region defined by its absolute bit offset and size. The complete structure of the message is therefore fully

15

determined by the set of containers and their associated properties. The following constraints apply • containers must not overlap; • all containers must be fully contained within the message boundaries; • the combination of all containers must provide a complete and unambiguous description of the message structure.

4.3 Implementation Examples This section presents representative examples demonstrating how the proposed message model can be applied to specific communication protocols. The purpose of these examples is to illustrate how message structures can be described using the unified modeling approach. In each case, a message is represented as a collection of containers defined over a common bit-addressed space. Each container is assigned an explicit role, data type, and absolute bit offset within the message.

16

4.3.1 ARINC 429 An ARINC 429 message consists of a fixed-length 32-bit word containing multiple logically distinct fields. Using the proposed model, such a message can be represented as a set of containers defined over a shared bit-addressed structure as shown in Table 5. It should be noted that, according to the ARINC 429 standard, signed parameters are traditionally encoded by placing the sign bit in the most significant bit of the data field (in this example, bit 28), rather than using the more common two’s complement representation. A strictly conventional ARINC 429 interpretation would therefore treat this bit as part of the SSM field. In the proposed model, however, this bit is intentionally retained as part of the payload container, resulting in a simpler and more consistent representation of the encoded parameter. This modeling choice does not apply universally. For example, in cases involving SSM matrices of BCD type, separation of the sign from the matrix structure must be handled explicitly. The proposed model supports such cases, but requires a different container decomposition. Table 5 ARINC 429 message example

Bits 0..7

Name Label

Role ID

8..9

SDI

ID

10..28

A11_Pitch

PL

29..30

SSM

PL

31

ParityBit

CRC

Data Type int, unsigned, 8 bits

Endianness Value Comment byte: LE, 212 Decimal representabit: LSBF tion 212d stands for octal representation 324o. int, unsigned, 8 byte: LE, 0 Source Destination bits bit: LSBF Identifier. fixed-point, byte: LE, – Sign encoding is signed (sign bit, bit: LSBF “sign bit, MSB”. MSB), 19 bits, Specified resoluRes: tion results in MSB 0.0006866455, weight of 90 degrees. Offset: 0 int, unsigned, 2 byte: LE, – Sign and Status bits bit: LSBF matrix, defines the validity of transmitted data. boolean N/A – –

Note: The examples in this section use the following acronyms and conventions: ID – identifier; PL – payload; CRC – cyclic redundancy check (and analogous integrity-check fields); LEN – length; LSB/MSB – least/most significant bit; LE/BE – little-/big-endian (byte order); LSBF/MSBF – least/most significant bit first; Res. – resolution.

17

4.3.2 CAN BFF Example in Table 6 describes a CAN message with basic identifier and demonstrates several important aspects of the proposed modeling approach. First, to ensure consistent interpretation of frame headers across platforms, all identifier-related containers must be explicitly defined, including RTR and IDE fields. Second, although CAN is formally defined as a big-endian protocol, practical experience shows that commercial off-the-shelf (COTS) implementations may deviate from this convention. The proposed model allows such variations to be represented explicitly at the container level without introducing ambiguity into the message definition. Table 6 CAN BFF message example

Bits 0..10

Name ID

Role ID

11

RTR

ID

12

IDE

ID

13

r0

OTH

14..17

DLC

LEN

18..33

A0Crnt

PL

34..49

A16ChEst

PL

50..57

A32TMin

PL

58..65

A40TMax

PL

66..80

CRC

CRC

Data Type Endianness Value Comment int, unsigned, 11 byte: BE, 12345 Identifier. bits bit: MSBF boolean N/A 0 Must be dominant (0) for data frames and recessive (1) for remote request frames. boolean N/A 0 Identifier extension bit (IDE). Must be dominant (0) for base frame format. boolean N/A 0 Reserved bit. Must be dominant (0). int, unsigned, 4 byte: N/A, 6 Data Length Code. bits bit: MSBF fixed-point, byte: LE, – Even though CAN signed (2’s bit: MSBF is big-endian by compl.), 16 bits, design, some data Res.: 0.1, Offset: may be encoded as 0 little-endian. fixed-point, byte: LE, – Even though CAN signed (2’s bit: MSBF is big-endian by compl.), 16 bits, design, some data Res.: 0.1, Offset: may be encoded as 0 little-endian. fixed-point, byte: N/A, – Resolution/offset unsigned, 8 bits, bit: MSBF combination results Res.: 1, Offset: in a full range of -100 -100..155 degrees. fixed-point, byte: N/A, – Resolution/offset unsigned, 8 bits, bit: MSBF combination results Res.: 1, Offset: in a full range of -100 -100..155 degrees. int, unsigned, 15 byte: BE, – Checksum. bits bit: MSBF

18

4.3.3 CAN EFF Example in Table 7 presents a CAN message with extended identifier. A noteworthy aspect of this example concerns the representation of the extended CAN identifier. In engineering practice, it is common to treat the extended identifier as a single 29bit value (in this example, 145358852 or 0x8AA0004). However, in the actual frame structure, the identifier is not transmitted as a single contiguous field. Instead, it is split into two separate components: IDA (11 bits) and IDB (18 bits), separated by control fields within the frame layout. Table 7 CAN EFF message example

Bits 0..10

Name IDA

Role ID

11

SRR

ID

12

IDE

ID

13..30

IDB

ID

31

RTR

ID

32

r1

OTH

33

r0

OTH

34..37

DLC

LEN

38..69

ActPos1

PL

70..101

ActPos2

PL

102..116 CRC

CRC

Data Type Endianness Value Comment int, unsigned, 11 byte: BE, 554 First part of bits bit: MSBF the identifier. Full identifier equals 145358852 (0x8AA0004) in the example. boolean N/A 1 Substitute remote request. Must be recessive (1). boolean N/A 1 Identifier extension bit (IDE). Must be recessive (1) for extended frame format with 29-bit identifiers. int, unsigned, 18 byte: BE, 131076 Second part of the bits bit: MSBF identifier. boolean N/A 0 Must be dominant (0) for data frames and recessive (1) for remote request frames. boolean N/A 0 Reserved bit which must be set dominant (0), but accepted as either dominant or recessive. boolean N/A 0 Reserved bit which must be set dominant (0), but accepted as either dominant or recessive. int, unsigned, 4 byte: N/A, 8 Data Length Code. bits bit: MSBF floating point byte: BE, – Payload element. single bit: MSBF floating point byte: BE, – Payload element. single bit: MSBF int, unsigned, 15 byte: BE, – Checksum. bits bit: MSBF

19

The proposed model reflects the physical message structure rather than the conventional abstract representation. Accordingly, the identifier is described using two distinct containers (IDA and IDB), each defined at its corresponding bit offset. The complete identifier value is therefore reconstructed as: IDA × 218 + IDB. This example highlights an important advantage of the proposed modeling approach: it preserves the exact structural organization of transmitted data while still allowing higher-level interpretations to be derived where needed.

4.3.4 ARINC 825 ARINC 825 adopts the CAN extended frame format but redefines the interpretation of the header and introduces additional constraints on allowed data types and their placement. For this reason, a separate structural example is not provided, as the CAN EFF example in Table 7 already reflects the underlying message structure. However, in practical applications, users may need to work with ARINC 825specific abstractions and notation. The proposed modeling approach supports such use cases through configurable user representations, which allow alternative interpretations of the same underlying message structure. This capability is described in Sections 5 and 6.

20

4.3.5 UART Serial Message Example #1 This example, taken from practical applications, presents a message with a simple header consisting of an identifier and a cyclic message counter, followed by a payload composed of 12-bit signed values and a trailing CRC field. The example demonstrates that the proposed model is capable of representing non-standard and implementation-specific message formats with arbitrary field sizes and encoding rules. Table 8 UART serial message example #1

Bits 0..31

Name Header

Role ID

32..39

Step

OTH

40..51

D01_LSLR

PL

52..63

D02_LSFB

PL

228..239

D20_POTR

PL

240..255

CRC

CRC

Data Type Endianness Value Comment int, unsigned, 32 byte: BE, 16,777 Message Identibits bit: MSBF fier. int, unsigned, 8 byte: N/A, – Message counter. bits bit: MSBF int, signed (2’s byte: BE, – Payload element. compl.), 12 bits bit: MSBF int, signed (2’s byte: BE, – Payload element. compl.), 12 bits bit: MSBF ... int, signed (2’s byte: BE, – Payload element. compl.), 12 bits bit: MSBF int, unsigned, 16 byte: BE, – Checksum. bits bit: MSBF

21

4.3.6 UART Serial Message Example #2 MAVLink Table 9 presents a MAVLink 2 standard message ATTITUDE (30) with no signature. The example is taken from the official web documentation [23] Table 9 MAVLink message example

Bits 0..7

Name STX

Role Data Type ID int, unsigned, 8 bits

EndiannessValue Comment byte: N/A, 253 Protocol-specific bit: LSBF start-of-text (STX) marker. Value 253 equals 0xFD. 8..15 LEN LEN int, unsigned, 8 byte: N/A, 28 Payload length. bits bit: LSBF 16..23 Incompatibility ID int, unsigned, 8 byte: N/A, 0 Flags that must Flags bits bit: LSBF be understood for MAVLink compatibility; implementation discards the packet if it does not understand the flag. 24..31 Compatibility ID int, unsigned, 8 byte: N/A, 0 Flags that can Flags bits bit: LSBF be ignored if not understood; implementation may still process the packet. 32..39 Packet OTH int, unsigned, 8 byte: N/A, 198 Used to detect sequence bits bit: LSBF packet loss. Comnumber ponents increment this value for each transmitted message. 40..47 System ID ID int, unsigned, 8 byte: N/A, 1 ID of the system bits bit: LSBF (vehicle) sending the message. 48..55 Component ID ID int, unsigned, 8 byte: N/A, 1 ID of the compobits bit: LSBF nent sending the message. 56..79 Message ID ID int, unsigned, 24 byte: LE, 30 ID of the message bits bit: LSBF type in payload. 80..111 time_boot_ms PL int, unsigned, 32 byte: LE, – Timestamp (time bits bit: LSBF since system boot) in milliseconds. 112..143 roll PL floating point byte: LE, – Roll angle in radisingle bit: LSBF ans. ... 272..303 yawspeed PL floating point byte: LE, – Yaw angular speed single bit: LSBF in radians per second. 304..319 Checksum CRC int, unsigned, 16 byte: LE, – CRCbits bit: LSBF 16/MCRF4XX for the message.

22

4.3.7 UDP Table 10 illustrates a message whose header corresponds to the Ethernet–IP–UDP protocol stack. As shown in the table, the header occupies 42 bytes and consists of multiple fields defined across different protocol layers. At first glance, such an explicit definition may appear excessive. However, this level of detail is required to satisfy the requirement R2 — Complete message specification, ensuring that the message structure is fully and unambiguously defined. The presence of a complete structural description does not imply that all elements must be actively used by all consumers of the model. For example, certain header fields may not be explicitly set in generated code. Nevertheless, their inclusion guarantees that all required information is available for any component that depends on it. A practical challenge associated with such complete definitions is usability. This issue is addressed through configurable user representations, which allow the model to be presented and edited in a more convenient form. Details are provided in Sections 5 and 6.

4.4 Message Model Summary The proposed message model provides a fully explicit and deterministic description of message structure. All requirements formulated in Section 4.1 are satisfied: the model supports heterogeneous communication protocols, enables complete reconstruction of message binary representation, and does not impose artificial restrictions on data representation. The model achieves this by combining: • a flexible data type system, • a container-based structural representation, • and a bit-accurate definition of message structure. As a result, message definitions are unambiguous, implementation-independent, and suitable for automated processing. At the same time, the explicit nature of the model introduces practical challenges. Direct manual creation and maintenance of message descriptions in this form may be labor-intensive and error-prone, especially for complex protocols or large interface definitions. To enable practical application of the proposed approach, additional methods and supporting tooling are required. In particular, it is necessary to provide: • mechanisms for defining and enforcing structural constraints (e.g., message types); • automated creation of mandatory containers and structural elements; • user-friendly representations (user representations) for efficient inspection and editing of message definitions; • configurable user interfaces that allow adaptation of the model representation to domain-specific conventions (e.g., CAN vs. ARINC 825 interpretations). These aspects are addressed in the following sections.

23

Table 10 UDP message example

Bits

Name

Role Data Type 0..47 MAC_Destination ID int, uns., 48 bits 48..95 MAC_Source ID int, uns., 48 bits 96..111 Ethertype ID int, uns., 16 bits 112..115 IP_Version ID int, uns., 4 bits 116..119 IP_IHL ID int, uns., 4 bits 120..125 IP_DSCP ID int, uns., 6 bits 126..127 IP_ECN OTH int, uns., 2 bits 128..143 IP_TotalLen LEN int, uns., 16 bits 144..159 IP_Ident OTH int, uns., 16 bits

Endianness Value Comment byte: BE, bit: LSBF byte: BE, bit: LSBF byte: BE, bit: LSBF byte: N/A, bit: LSBF byte: N/A, bit: LSBF byte: N/A, bit: LSBF byte: N/A, bit: LSBF byte: BE, bit: LSBF byte: BE, bit: LSBF

0

160..162 IP_Flags

OTH int, uns., 3 bits 163..175 IP_FrgmOffset OTH int, uns., 13 bits 176..183 IP_TTL OTH int, uns., 8 bits 184..191 IP_Protocol ID int, uns., 8 bits 192..207 IP_HeaderCRC CRC int, uns., 16 bits 208..239 IP_SrcAddress ID int, uns., 32 bits

byte: N/A, bit: LSBF byte: BE, bit: LSBF byte: N/A, bit: LSBF byte: N/A, bit: LSBF byte: BE, bit: LSBF byte: BE, bit: LSBF

0

240..271 IP_DstAddress

ID

int, uns., 32 bits

byte: BE, bit: LSBF

272..287 UDP_SrcPort

ID

int, uns., 16 bits ID int, uns., 16 bits LEN int, uns., 16 bits CRC int, uns., 16 bits PL floating point double PL floating point double

byte: BE, bit: LSBF byte: BE, bit: LSBF byte: BE, bit: LSBF byte: BE, bit: LSBF byte: BE, bit: LSBF

288..303 UDP_DstPort 304..319 UDP_Length 320..335 UDP_CRC 336..399 A0ActPosCh1 400..461 A32ActPosCh2

byte: BE, bit: LSBF

24

0 2048 4 5 0 0 156 0

0 255 17 –

Destination MAC address. Source MAC address. Value 0x0800 stands for IPv4. Always 4 for IPv4. Internet Header Length. Differentiated Services Code Point. Explicit Congestion Notification. Total IP packet size in bytes Identification field for fragmented datagrams. This feature is not considered. This feature is not considered. This feature is not considered. Value 17 stands for UDP. IPv4 header checksum

3,232, IPv4 address of 235, the sender. Value 777 3232235777 stands for “192.168.1.1”. 3, 232, IPv4 address of 235, the receiver. Value 778 3232235778 stands for “192.168.1.2”. 49001 Identifies the sender’s UDP port. 49002 Identifies the receiver’s UDP port. 136 Length of the UDP datagram in bytes. – UDP header and payload checksum. – Payload element. –

Payload element.

5 Methods for Working with the Model 5.1 Problem Statement The message model introduced in Section 4 provides an explicit and fully defined representation of message structure. However, constructing and maintaining message descriptions directly at this level of detail is impractical in real engineering workflows. Manual specification of containers and their properties is time-consuming, error-prone, and difficult to scale, particularly when working with large interface datasets. To enable effective practical use of the proposed model, structured methods are required for constructing, maintaining, and validating message descriptions. These methods must satisfy the following requirements. T1. Constraint-based consistency. The methods shall support maintaining consistency between message definitions and user-defined structural and semantic constraints. Explanation. Such constraints may be derived from communication standards or from project-specific protocols, including cases where the corresponding rules are described only informally. The methods must therefore support both formalized and user-defined constraint sets. T2. Support for deterministic automation. The methods shall support automatic creation and completion of all message elements and properties that can be derived unambiguously from existing model data, constraint definitions, or user-provided engineering-level properties. Explanation. This includes, for example, automatic creation of mandatory containers and automatic assignment of their values when these values are uniquely determined by structural rules or by user-facing message properties. T3. User-oriented model interaction. The methods shall support presentation and editing of the formal model in a form convenient and familiar to the user. Explanation. The user should not be forced to work directly with the raw structural representation when a more natural engineering-oriented representation can be provided. T4. User-configurable representations. The representation format used for model presentation and editing shall be configurable by the user and shall not be hard-coded. Explanation. Different domains and workflows may require different engineering notations and abstractions. The methods must therefore allow the same formal model to be presented through different user-defined representations.

5.2 Implementation Basics The proposed implementation addresses the requirements stated above through two complementary mechanisms. First, a message type mechanism is introduced. In the context of this work, a message type is a user-defined description of allowable message structure, including structural constraints, permitted container configurations, and mandatory elements that

25

can be generated automatically. This mechanism provides the basis for consistency enforcement and support of deterministic automation. Second, configurable user representations are introduced for messages and containers. These representations allow the formal model to be viewed and edited in a user-oriented form while preserving a bidirectional mapping to the underlying structural definition. This mechanism provides convenient engineering interaction with the model and enables adaptation of the interface to different domain-specific conventions. Together, these two mechanisms address the full set of requirements formulated above: message types provide structured constraint handling and automation support, while configurable representations provide practical and user-adjustable access to the formal model. The message type mechanism is described in Section 5.3. The representation mechanism is described in Section 5.4.

5.3 Message Types 5.3.1 Mechanism Description Message types define the allowable characteristics and structural constraints of messages within a given communication domain. In practical workflows, message types serve as a primary mechanism for reducing manual effort and preventing structural inconsistencies. For example, when a user specifies that a message belongs to the CAN EFF type, this requirement uniquely determines the structure of the frame header and constrains the allowable payload organization. Message types therefore provide both structural guidance and validation capabilities for message definitions. Message types define the following properties: • Message properties constraints • Structural constraints Message properties constraints specify allowable size limits expressed in bits. Structural constraints define allowable message structures in terms of container types and their properties. For each container type, the following characteristics are specified: 1. Allowed address range. Range of permissible bit offsets for containers of this type 2. Container type name. 3. Container role. Functional role of the container described above. 4. Allowed data types. Either a defined set of permissible data types or an indication that any type may be used. 5. Allowed size range. Permissible bit-length range for containers of this type. 6. Minimum and maximum number of instances. The property specifying how many containers of this type may appear within a message. 7. Byte order (endianness). Defines the byte order used for the container. Can be either big- or little- endian. 8. Bit order. Defines the bit order. Can be either most-significant-bit-first or leastsignificant-bit-first.

26

9. Automatic creation flag. An indicator specifying whether containers of this type should be generated automatically when a message is created. Automatically generated containers are created during message instantiation based on the selected message type. Their primary purpose is to ensure consistent creation of mandatory structural elements such as identifier fields. To enable automatic creation, all defining properties of a container must be unambiguous. In particular, the data type, size, and placement constraints must be fully determined by the message type definition. Only containers meeting these conditions can be generated automatically without introducing ambiguity into the message model.

5.3.2 Example: CAN EFF Message Type Definition To illustrate the message type mechanism, this subsection presents a simplified CAN EFF message type definition derived from an actual implementation. The example shows how a message type captures both message-level constraints and structural rules governing container placement, size, encoding properties, and automatic creation. For the CAN EFF message type, the allowable message size ranges from 53 to 117 bits depending on payload length. These limits reflect protocol-specific structural overhead and define the valid range for all compliant message instances. The message structure is defined as a set of container types with explicitly constrained properties. Each container definition includes the properties specified in Section 5.3.1. The corresponding message type definition is shown in the table 11. Table 11 CAN EFF message structure definition

Address Name range 0..10 IDA

Role

Data Type

Qty.

ID

1

11 12 13..30

SRR IDE IDB

ID ID ID

31 32 33 34..37

RTR r1 r0 DLC

ID OTH OTH LEN

int, unsigned, 11 bits boolean boolean int, unsigned, 18 bits boolean boolean boolean int, unsigned, 4 bits

38..101

Payload_BE

PL

0..64

38..101

Payload_LE

PL

trailing 0..14

CRC

CRC

unrestricted, size: 1..64 bits unrestricted, size: 1..64 bits int, unsigned, 15 bits

1 1 1 1 1 1 1

0..64 1

Endianness AutoCreate byte: BE, yes bit: MSBF N/A yes N/A yes byte: BE, yes bit: MSBF N/A yes N/A yes N/A yes byte: BE, yes bit: MSBF byte: BE, no bit: MSBF byte: LE, no bit: MSBF byte: BE, yes bit: MSBF

This example illustrates several important aspects of the proposed message type mechanism. 27

First, the complete message structure is defined explicitly through constrained container types rather than implicit protocol knowledge. This enables deterministic validation and consistency enforcement of message definitions and eliminates ambiguity in implementation. Second, specification of data types for each container plays a fundamental role in the model. As defined in Section 4.2.2, data types determine encoding semantics and ensure consistent interpretation. Third, encoding properties such as byte order and bit order are defined explicitly for each container type, ensuring that the structural model fully captures transmission semantics across implementations and architectures. Fourth, mandatory structural elements such as identifiers, control fields, and CRC are configured for automatic creation, while flexible regions such as payload fields are defined through bounded ranges rather than fixed layouts. In this example, the two payload container types ("Payload_BE", "Payload_LE") represent alternative allowable configurations (byte endianness) rather than simultaneously present elements of the same message instance. The CRC placement is defined relative to the end of the message because its absolute position depends on payload size.

5.4 User Representation Method 5.4.1 Mechanism Description Core Idea The proposed approach introduces a two-level representation mechanism designed to make the detailed message model practical for everyday engineering use. The key idea is to separate the internal model representation from the user-facing representation while maintaining a well-defined functional relationship between them. For both messages and containers, the representation is organized into two independently defined but functionally linked levels: • Data-level representation, which corresponds directly to the underlying formal model; • User-level representation, which defines how the same information is presented and edited by engineers. The data-level representation operates directly on model properties, while the userlevel representation defines the structure and semantics of the interface visible to users. The key property of this mechanism is its bidirectional nature: the same configuration defines both how model data is presented to the user and how user input is translated back into the formal model. The user representation is therefore not merely a visualization layer, but an operational interface for constructing and modifying the formal message description. All mappings, visibility rules, and transformations should be fully configurable and defined independently of message type. This allows the same structural model to

28

support different engineering conventions without introducing parallel message type definitions. An important aspect of the proposed approach is that message-level representations may include not only properties of the message itself but also selected properties of nested containers, particularly those that are unique and automatically generated. For example, identifier values are often exposed directly at the message level, while in the formal model they are represented as properties of containers with the "Identifier" role. Similarly, modifying a message-level property such as payload size may simultaneously update both the corresponding message attribute and nested container values. Not all containers included in the full structural representation are relevant for routine user interaction. In practice, users often prefer to hide: • identifier- or length-related containers as they are already exposed at the message level, • automatically generated elements such as CRC fields. Core Idea Example: Payload-Oriented Size Representation The advantages of the proposed mechanism can be illustrated using a typical case where the formal model and engineering practice rely on different abstractions. In the formal model, message size is defined as the total number of bits in the frame. In contrast, engineers often work with payload size expressed in bytes. Since the size of protocol overhead is fixed for a given message type, the user-level representation can define payload size as a derived property computed from the total message size. For example, in CAN EFF: SIZEgui = (SIZEmodel - 53)/8, where 53 is a size of overhead in bits. The corresponding reverse transformation allows user-edited payload size values to be translated back into total frame size and associated structural elements. For example, in CAN EFF: SIZEmodel = SIZEgui*8+53 As a result, engineers can operate using familiar abstractions while the underlying model remains complete and structurally explicit.

5.4.2 Use Case Example for CAN EFF To illustrate the proposed representation method, this section presents an example configuration for a CAN_EFF message. The purpose of the example is not to describe the full configuration syntax, but rather to demonstrate the key principles of the method described above. Message-Level Representation For the message type CAN_EFF, the user-facing representation is configured independently of the underlying message model. At the message level, the user is presented with a compact set of engineering-oriented message properties, including properties derived from the underlying containers. A simplified pseudoconfiguration is shown below:

29

Message representation: CAN_EFF User-visible properties: FID_dec := ContainerValue(IDA)*2^18 + ContainerValue(IDB)*** FID_hex* := DecToHex(ContainerValue(IDA)*2^18 + ContainerValue(IDB))*** DLC** := (Size_bits - 53) / 8 Name* := If(Description="", "F"+FID_dec, "F"+FID_dec+"_"+Description) Direction := Direction RefreshRate_ms := RefreshRate_ms Description := Description *Read-only properties are marked with asterisk **DLC represents the size of the payload in bytes, while Size_bits is the size of the complete message in bits. 53 bits is a sum of all identifiers, checksums etc. *** ContainerValue is a function that returns the value of the nested container with the specified name. This representation demonstrates that the user-visible message view does not need to mirror the structural composition of the underlying frame. Instead, it can expose only those properties that are meaningful for routine engineering tasks. In particular: • the extended CAN identifier is shown as a single value, although it is physically represented in the message as two separate containers, IDA and IDB; • the size shown to the user is the payload-oriented value DLC, rather than the total message size in bits; • naming can be dynamically derived from message properties rather than stored as a separate model element. Message-Level Reverse Transformation The representation method is bidirectional. In addition to deriving user-facing properties from the model, it also defines how user input is translated back into raw model data. For the same example, the reverse transformations may be expressed as follows: Message Reverse transformations: CAN_EFF IDA := floor(FID_dec / 2^18) IDB := FID_dec mod 2^18 Size_bits := 8*DLC + 53 DLC.value := DLC Direction := Direction RefreshRate_ms := RefreshRate_ms Description := Description

30

This illustrates two important cases. First, a single user-visible property may be mapped back into multiple model elements. For example, editing FID_dec updates both IDA and IDB. Second, a user-visible property may simultaneously affect a message-level property and a nested container. For example, editing DLC updates the total message size as well as the value of the corresponding DLC container. This mechanism allows engineers to work with familiar abstractions while preserving a fully explicit and structurally accurate formal model underneath. Container-Level Representation A separate representation is configured for payload containers. Here again, the userfacing view is adapted to engineering practice rather than to the raw bit-level message structure. Since this representation is intended specifically for payload elements, non-payload structural containers such as identifier fields, length-related elements, and checksum fields are hidden from this view. In the message model, container addresses are defined as absolute bit offsets from the beginning of the message. In the user-facing representation, however, addresses are displayed relative to the beginning of the payload area. In this example, container names are also derived automatically: each name is composed of an address-based prefix and the container description. A simplified pseudoconfiguration is shown below: Container representation: CAN_EFF payload Hidden containers: IDA, IDB, CRC, SRR, RTR, IDE, r0, r1, DLC Visible properties: Address := Address_model - 38 Name* := If(Description="", "A"+Address, "A"+Address+"_"+Description) DataType := DataType Size := Size Resolution := Resolution Offset := Offset Sign := Sign Description := Description *Read-only properties are marked with asterisk Container-Level Reverse Transformation The container-level reverse transformation is as simple as: Address_model := Address + 38 DataType := DataType Size := Size 31

Resolution := Resolution Offset := Offset Sign := Sign As a result, the engineer works with payload-relative coordinates, while the model retains the absolute addressing required for deterministic message construction, validation, and code generation. Discussion This example demonstrates that the proposed representation method is not limited to passive formatting of model data. Instead, it provides a configurable, bidirectional transformation layer between the formal message model and the user-facing engineering representation. This makes it possible to: • expose only relevant properties to the user, • hide automatically generated or structurally derived elements, • present data in forms consistent with protocol documentation and engineering conventions, • transform user input back into a complete and explicit message model. An important implication of the proposed representation method is that different user-facing views can be configured for the same underlying frame structure. A representative example is ARINC 825, which relies on the same underlying frame definition as CAN EFF. The primary differences arise from how the frame header is interpreted and represented: ARINC 825 conceptually decomposes the identifier field into separate components and imposes additional constraints on allowable payload data types and their placement. However, these differences do not affect the underlying structure of the frame. Using the proposed representation method, CAN EFF and ARINC 825 can therefore share the same formal message model while employing different user representations. This demonstrates that the method separates the structural description of a message from its engineering interpretation and allows multiple domain-specific views to coexist over the same underlying data.

6 Modelling Tool Example 6.1 Implementation Approach The proposed modeling approach has been implemented in an industrial MBSE tool environment dBricks [32], which serves as a reference implementation of the concepts described in this paper. In the implemented environment, configuration of message types and user representations follows directly the methodology introduced in Sections 4 and 5. Message type definitions specify structural constraints, container roles, encoding properties, and automatic-generation rules. Representation configurations define user-oriented views and bidirectional transformations between the formal model and engineering-facing abstractions. 32

As a result, the tool does not introduce additional modeling concepts beyond those described in this work; instead, it provides a practical environment for their consistent application in real development workflows.

6.2 Message Creation and Editing Workflow This example demonstrates how the proposed modeling approach operates in a real engineering workflow. Figure 3 shows the message creation form used to define a new CAN extended frame (CAN EFF) message. Note: dBricks SW uses the term "Frame" as synonym for "Message"

Fig. 3 "Create Frame" form for CAN EFF

At creation time, the user specifies only high-level engineering properties exposed by the configured representation. In this example, these include the message type, identifier value (FID_dec), payload size (DLC), direction, refresh rate, transmission control parameter, and description. Notably, no protocol-level structural elements are defined manually. The user does not specify container composition, addressing, encoding properties, or control fields such as IDA, IDB, or CRC. These elements are instead derived automatically from the selected message type and associated constraints. Following message creation, the tool automatically generates a complete structural representation of the frame based solely on the selected message type.

33

Fig. 4 CAN EFF raw structural representation after creation

Figure 4 shows the resulting structural definition immediately after message creation. All mandatory protocol-level containers—including IDA, IDB, reserved fields, DLC, and CRC—are generated automatically according to the configured constraints. The generated structure reflects the exact physical layout of the CAN EFF frame, including correct addressing of all elements and placement of the CRC container at the end of the message. Values for identifier-related containers and the length container are assigned automatically. In this example, the identifier entered by the user is decomposed into IDA and IDB components, while the DLC container is assigned the corresponding payload size value. In parallel with the structural representation, the tool provides a user-oriented view of the message definition derived from the same underlying model.

Fig. 5 CAN EFF message user representation after creation

Figure 5 shows the configured message-level representation of the same CAN EFF frame. Instead of exposing the full structural composition, this view presents a compact set of engineering-relevant properties, including the identifier value in both decimal and hexadecimal form, payload size (DLC), direction, and refresh rate. Protocol-level structural elements such as IDA, IDB, control fields, and CRC remain hidden in this view, although they are fully defined in the underlying model. Despite the simplified presentation, all values shown here are directly derived from the formal message definition. Figure 6 shows the update form where both the identifier value and payload size (DLC) are modified by the user. As in the creation stage, only high-level engineering properties are edited, while protocol-level structural elements remain hidden from direct interaction. These changes trigger automatic updates of the underlying structural representation. Figure 7 shows the updated structural representation after modifying both the identifier and payload size. The underlying model is automatically recalculated without any manual adjustments to protocol-level elements. The identifier value entered 34

Fig. 6 "Update Frame" form for CAN EFF

Fig. 7 CAN EFF raw structural representation after update

by the user is decomposed into updated IDA and IDB containers, while the DLC container reflects the new payload size. In addition, dependent structural elements are repositioned automatically: in particular, the CRC container is moved according to the new message length.

Fig. 8 CAN EFF message user representation after modification

35

The corresponding user-oriented representation is shown in Figure 8. The updated identifier value is presented consistently in both decimal and hexadecimal form, and the payload size reflects the modified DLC value. Together, these examples confirm that changes introduced through the user-facing interface are propagated deterministically to the raw message model, demonstrating the bidirectional consistency of the proposed approach.

6.3 Payload Container Definition Workflow This subsection demonstrates how payload containers are defined and integrated into the message structure using the proposed modeling environment.

Fig. 9 Payload container creation form

Figure 9 shows the container creation form used to define a new payload element. As in the message-level workflow, the user interacts only with a limited set of engineering-relevant properties exposed through the configured representation. In this example, the user specifies the container type (Payload_BE), payloadrelative address, data type, and description. Importantly, the address is defined relative to the beginning of the payload area rather than the beginning of the message. This allows engineers to work within a coordinate system consistent with protocol documentation and common engineering practice.

36

Low-level structural properties such as absolute addressing, encoding semantics, and container placement constraints are not specified manually at this stage. Instead, they are derived automatically from the definitions made earlier. After creation, the new container becomes part of the complete structural representation of the message.

Fig. 10 Raw structural representation after container creation

Figure 10 shows the raw structural definition following container insertion. The newly created payload container appears within the unified bit-addressed message structure at the correct absolute offset. In this example, the container is placed at bit position 38, reflecting automatic conversion from payload-relative addressing to the absolute coordinate system used by the formal model. The same container is also visible in the user-oriented representation.

Fig. 11 User representation of container

Figure 11 shows the configured payload-level representation of the same container. In this view, the container is presented using payload-relative addressing and engineering-oriented attributes such as name, data type, and linked parameter. Containers of roles other than "payload" are hidden, as they are not required for routine engineering tasks. Together, these examples illustrate that container definition follows the same principles established earlier for message-level operations: engineers work with domainrelevant abstractions, while the tool maintains a fully explicit structural representation underneath.

37

6.4 ARINC 825 Message Representation Example As noted above, ARINC 825 is based on the CAN EFF frame format. Consequently, the message created in Section 6.2 can also be presented using an ARINC 825-oriented representation. Before demonstrating the configured representation, it is useful to recall the main difference between the conventional CAN EFF view and the ARINC 825 interpretation of the same frame header. In common CAN engineering practice, the identifier is usually handled as a single decimal or hexadecimal value. In ARINC 825, however, the same header is interpreted as a composition of several subfields: • LCC - Logical Communications Channel, • Source FID - Source Function Code Identifier, • RSD - Reserved bit, • LCL - Local bit, • PVT - Private bit, • DOC - Data Object Code, • RCI - Redundancy Channel Identifier. Figure 12 illustrates the conceptual correspondence between the CAN EFF header and its ARINC 825 interpretation.

Fig. 12 Comparison of CAN EFF and ARINC 825 header interpretations

Using the configurable representation mechanism, the frame F145358852_ActPosition, introduced in Section 6.2, can be presented in ARINC 825 form without modifying its underlying structural definition.

Fig. 13 ARINC 825-configured representation of CAN EFF frame

In the representation presented at Fig. 13, the identifier is no longer shown as a single aggregate numeric value. Instead, it is decomposed into ARINC 825-specific subfields, which provides a more meaningful engineering interpretation of the same underlying header structure: • LCC = 2 — Normal Operation Channel • Source FID = 21 — Source device identifier within the network • RSD = 0 • LCL = 1 — Message is local • PVT = 0 — Message is not private • DOC = 1 — Identifier of the data object within the source device message set • RCI = 0 — Redundancy channel identifier is either zero or not used 38

The decimal and hexadecimal header values are retained in the representation for reference. This example demonstrates that the proposed method allows the same formal message model to support multiple engineering views, depending on domainspecific interpretation requirements, without changing the underlying frame structure.

6.5 Ethernet-IP-UDP Message Representation Example The UDP-based example used in this paper contains the most structurally extensive header among the considered message types. For this reason, it provides a good use-case demonstration of how the proposed modeling approach handles message definitions with a large number of automatically maintained structural elements. The purpose of this example is to show that even a highly detailed message model can be created and edited in practice without overloading the user with routine low-level input. The first step is to create the message through the configured user-facing form as shown in Fig. 14.

Fig. 14 "Create Frame" form for UDP

After creation, the tool automatically generates the mandatory message structure shown in Figure 15. This example illustrates several important aspects of the implemented approach. First, although the complete Ethernet–IP–UDP header structure is present in the underlying model, only the subset relevant to the target engineering workflow needs 39

Fig. 15 UDP message raw structural representation after creation

to be exposed in the user-facing representation. In the configuration used for this example, MAC addresses are not required by the intended application and therefore remain unspecified. This does not limit the model itself and can be changed later by adapting the representation if such information becomes relevant. Second, some values are represented differently in the raw message model and in the engineering-oriented view. For example, IP addresses are stored internally as machine-processable integer values, while the configured representation exposes them in the conventional "192.168.101.101" notation familiar to engineers. Third, structural elements that can be derived automatically are maintained automatically. For example, length fields corresponding to different protocol layers are maintained automatically rather than entered manually by the user. Because the fully explicit header structure is not convenient for routine user interaction in this case, the configured engineering representation is limited to the properties typically needed in practice, such as IP addresses and UDP ports. An example of this user-oriented view is shown in Figure 16.

Fig. 16 UDP message user representation

6.6 Model Consistency Enforcement In addition to providing structured mechanisms for message and container definition, the implemented environment includes automated consistency enforcement functions designed to ensure correctness of the resulting models. 40

These mechanisms operate continuously during model creation and modification and address several classes of structural and semantic constraints. First, the tool verifies structural consistency of container placement within the message. In particular, it detects overlapping container definitions, ensures that all containers remain within message boundaries, and validates placement against constraints defined by the selected message type. Second, the tool enforces constraints on permissible data types. Container definitions are validated against message-type rules governing allowable data representations, preventing structurally valid but semantically incorrect configurations. Third, user-defined values are validated against configurable constraints designed to ensure downstream usability. For example, naming rules restrict the use of special characters that may be incompatible with target programming languages or codegeneration environments. Additional consistency checks address a broader range of project-specific requirements, including constraints derived from coding standards, integration rules, and toolchain assumptions. A detailed discussion of these mechanisms lies beyond the scope of this paper; however, their presence is essential for practical deployment of the proposed modeling approach in large-scale engineering workflows. Together, these consistency enforcement mechanisms complement the structural definition capabilities of the model and play a key role in enabling reliable automation of transport-layer software generation and interface verification activities.

41

6.6.1 Validation Against the Stated Requirements The proposed model, methods, and tool implementation were validated against the requirements formulated in Sections 4 and 5. Table 12 summarizes this validation effort. It shows how the stated requirements are addressed by the proposed solution and where their fulfillment is demonstrated in the paper. Table 12 Traceability between stated requirements and proposed solution

Req. Requirement text R1

R2

R3

T1

T2

T3

T4

Addressed by

Demonstrated in Protocol universality - The model must be Models of Data Examples for capable of representing message formats Type (4.2.2), ARINC 429/825, used across heterogeneous communication Container (4.2.3), CAN EFF/BFF, protocols, including both standardized and Message (4.2.4) MAVLink, and custom serial message structures. UDP/IP in Sections 4 and 6 Complete message specification - A Models of Data Structural complete message instance must be Type (4.2.2), examples and constructible solely from information Container (4.2.3), explicit message contained in the model. Message (4.2.4) tables in Section 4 Data representation flexibility - The model Addressing of all Structural must not impose artificial or encoding details examples with standard-driven restrictions on data types, in models of data different encoding addressing schemes, or value representations type (4.2.2) and schemes in used within message structures Container (4.2.3) Section 4 Constraint-based consistency - The methods Message type Message creation shall support maintaining consistency concept and and editing between message definitions and userrelated methods presented in defined structural and semantic constraints described in Sections 6.2 and Section 5.3 6.3 Support for deterministic automation - The Message type Message creation methods shall support automatic creation concept and and editing and completion of all message elements and related methods presented in properties that can be derived described in Sections 6.2 and unambiguously from existing model data, Section 5.3 6.3 constraint definitions, or user-provided engineering-level properties. User-oriented model interaction - The User User methods shall support presentation and representation representations editing of the formal model in a form method described given in Section 6 convenient and familiar to the user. in Section 5.4 User-configurable representations - The User User representation format used for model representation representations presentation and editing shall be method described given in Section 6 configurable by the user and shall not be in Section 5.4 hard-coded.

42

7 Conclusion Efficient development of modern embedded systems increasingly depends on the use of automation toolchains. To be effective, such toolchains must rely on a solid formal basis. One of the key elements of this basis is a machine-readable ICD. To make such an ICD both practically useful and broadly applicable across heterogeneous communication environments, it should be built on a unified serial message model of the transport layer. In this work, we proposed a unified and protocol-agnostic message model that makes it possible to describe serial messages explicitly and unambiguously, regardless of the protocol family to which they belong. The model is based on three elements: an explicit description of data types as the basic encoding units, a description of atomic message elements (containers) together with their required properties, and a description of complete message structure built from these atomic elements. In addition to the model itself, the paper proposed methods for working with it in practice. These methods are based on two main mechanisms. The first is a configurable formal message type model, which supports both automation of routine operations and definition of structural constraints. The second is a configurable representation mechanism that allows the unified formal model to be presented and edited in forms convenient for engineering reading and editing. The paper also demonstrated successful implementation of the proposed model and methods in the industrial tool dBricks. Taken together, the model, the methods, and the tool implementation form a workable foundation for automation toolchains intended to support machine-readable ICD development, automated generation of transport-layer software and all related transport-layer engineering tasks.

References [1] Annighoefer B, Halle M, Schweiger A, et al (2019) Challenges and ways forward for avionics platforms and their development in 2019. In: 2019 IEEE/AIAA 38th Digital Avionics Systems Conference (DASC), https://doi.org/10.1109/ DASC43569.2019.9081794 [2] Tietz V, Frey C, Waldvogel A, et al (2024) Why the use of domain-specific modeling in airworthy software requires new methods and how these might look like? Innovations in Systems and Software Engineering https://doi.org/10.1007/ s11334-024-00565-2 [3] Mueller P, Merckling M, Tietz V, et al (2023) Introduction of a dedicated platform level for ima systems development with an extensive automation tool support. In: 2023 IEEE/AIAA 42nd Digital Avionics Systems Conference (DASC), https: //doi.org/10.1109/DASC58513.2023.10311128 [4] Brahmi A, Delmas D, Essoussi MH, et al (2018) Formalise to automate: Deployment of a safe and cost-efficient process for avionics software. In: Proceedings of the 9th European Congress on Embedded Real Time Software and Systems 43

(ERTS 2018) [5] Rhein J, Sinitsyn V, Holzapfel F (2022) A holistic approach to model-based avionics systems development. In: 2022 IEEE/AIAA 41st Digital Avionics Systems Conference (DASC), https://doi.org/10.1109/DASC55683.2022.9925749 [6] Chrysalidis P, Thielecke F (2024) Universal configuration format for virtual, hybrid and hardware testing of avionic platforms. In: 2024 IEEE/AIAA 43rd Digital Avionics Systems Conference (DASC), https://doi.org/10.1109/DASC62030. 2024.10749091 [7] Annighoefer B, Schoepf J, Waldvogel A (2022) From user stories to an optimal digital work environment for ima system development. In: 2022 IEEE/AIAA 41st Digital Avionics Systems Conference (DASC), https://doi.org/10.1109/ DASC55683.2022.9925783 [8] Cadavid H, Andrikopoulos V, Avgeriou P (2023) Improving hardware/software interface management in systems of systems through documentation as code. Empirical Software Engineering 28(4):100. https://doi.org/10.1007/ s10664-023-10350-7 [9] Halle M, Thielecke F (2021) Avionics next-gen engineering tools (avionet): Experiences with highly automised and digital processes for avionics platform development. In: 2021 IEEE/AIAA 40th Digital Avionics Systems Conference (DASC), https://doi.org/10.1109/DASC52595.2021.9594509 [10] Brahmi A, Carolus MJ, Delmas D, et al (2020) Industrial use of a safe and efficient formal method based software engineering process in avionics. In: Embedded Real Time Software and Systems (ERTS 2020) [11] Panchal P, Dmitriev K, Myschik S, et al (2023) Comprehensive overview of a process-oriented build tool for airborne safety-critical software development. In: 2023 10th International Conference on Recent Advances in Air and Space Technologies (RAST), https://doi.org/10.1109/RAST57548.2023.10197990 [12] Hochstrasser MT (2020) Modular model-based development of safety-critical flight control software. Dissertation, Technical University of Munich [13] Sinitsyn V, Schlautmann N, Schwaiger F, et al (2025) Streamlined airborne software development for large uavs: From unified data collection to automated code generation. In: 2025 IEEE/AIAA 44th Digital Avionics Systems Conference (DASC), https://doi.org/10.1109/DASC66011.2025.11257298 [14] ISO (2015) Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling. International Organization for Standardization, Geneva

44

[15] Postel J (1981) Internet protocol. Tech. Rep. RFC 791, Internet Engineering Task Force, Marina del Rey, CA [16] Postel J (1980) User datagram protocol. Tech. Rep. RFC 768, Internet Engineering Task Force, Marina del Rey, CA [17] Hornig C (1984) A standard for the transmission of ip datagrams over ethernet networks. Tech. Rep. RFC 894, Internet Engineering Task Force, Marina del Rey, CA [18] Aeronautical Radio, Inc. (2004) ARINC Specification 429, Part 1-17: Mark 33 Digital Information Transfer System (DITS), Functional Description, Electrical Interface, Label Assignments and Word Formats. Aeronautical Radio, Inc., published May 17, 2004 [19] AUTOSAR (2024) AUTOSAR CP System Template. AUTOSAR, release R24-11 [20] Vector Informatik GmbH (2018) CANdb++ Manual. Vector Informatik GmbH, vendor documentation for the de facto DBC format [21] ITU-T, ISO/IEC (2021) Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic notation. International Telecommunication Union and International Organization for Standardization [22] SAE International (2018) ARINC 825-4: General Standardization of Controller Area Network (CAN) Bus Protocol for Airborne Use. SAE International, Warrendale, PA, published September 2018 [23] MAVLink (2026) Protocol overview. URL https://mavlink.io/en/about/ overview.html [24] ISO (2025) Road vehicles — Local Interconnect Network (LIN) — Part 3: Protocol specification. International Organization for Standardization, Geneva [25] ISO (2013) Road vehicles — FlexRay communications system — Part 2: Data link layer specification. International Organization for Standardization, Geneva [26] ASAM e.V. (2017) ASAM MCD-2 NET (FIBEX): Data Model for ECU Network Systems. ASAM e.V., release date: 02 Jun 2017 [27] LIN Consortium (2010) LIN Configuration Language Specification. LIN Consortium, revision 2.2a edn., part of the LIN Specification Package 2.2A [28] Annighoefer B, Brunner M (2021) Open source domain-specific model interface and tool frameworks for a digital avionics systems development process. In: 2021 IEEE/AIAA 40th Digital Avionics Systems Conference (DASC), https://doi.org/ 10.1109/DASC52595.2021.9594380

45

[29] Annighoefer B, Luettig B, Brunner M, et al (2020) Holistic ima platform configuration using web-technologies and a domain-specific model query language. In: 2020 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC) [30] Watkins CB, Ross J, Varghese J, et al (2022) Data-message modeling for multi-lane architectures on an ima platform using the esam method. In: 2022 IEEE/AIAA 41st Digital Avionics Systems Conference (DASC), https://doi.org/ 10.1109/DASC55683.2022.9925816 [31] Watkins CB, Varghese J, Knight M, et al (2020) System architecture modeling for electronic systems using mathworks system composer and simulink. In: 2020 IEEE/AIAA 39th Digital Avionics Systems Conference (DASC) [32] PEERSS GmbH (2026) dbricks tool overview. URL https://peerss.net/dbricks/

46

Related documents

• EIP: The Extended Internet Protocol#131418
• Simple Internet Protocol Plus White Paper#141803
• Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol#134733
• TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing#136691
• Internet Open Trading Protocol Version 2 Requirements#135035