The Role of a Consistent Data Model for Systems Development

Date: 11 ноября 2020

With this article we explain the dBricks data model in a simplified form and we highlight the reasons why we realized it in this way.

For better understanding we use system examples from the field of aerospace. But please recognize that dBricks can be used for any system development of any technical sector.

Our goal is to optimize the:

  • development of highly integrated electronic systems
  • composed of hundreds of separate devices
  • built by tens of suppliers

The must-have prerequisite for success is the consistent and explicit definition of all interfaces between the system devices.

To implement a system means to fulfill a bunch of considerations and decisions. All of them must be done consistently and every design aspect affects other system properties. Having a consistent method to avoid iterations saves a lot of effort.
The following steps show how you can act according to best practice.

Step #1: First System Approach

Any system is composed of actors that exchange data. In case of an aircraft subsystem these actors are so called devices. These devices:

  • perform dedicated tasks and
  • interact with each other by exchanging parameters

For example:

The pilot needs the information of the actual pitch angle to control the airplane. This angle must be displayed on the so-called Display Unit (DU) inside the cockpit. The DU is not able to measure the pitch angle itself and therefore needs to receive this information. The Air Data and Inertial Reference Unit (ADIRU) measures the pitch angle of the aircraft and can provide this information to the pilot's DU.

Both device interfaces need to support the exchange of the parameter for pitch:

  • In case of ADIRU: OUT_PITCH
  • In case of DU: IN_PITCH

In order to interpret this parameter in the same way it is necessary to define parameter properties as well. Obviously both actors must interpret the parameter, in the same way, to use it correctly. In many development projects implicit data type conversions are the source of an enormous number of development problems!

For our pitch information we define the following properties and assignments:

  • Data type ==> FLOAT
  • Engineering Unit ==> degrees

In our system example we additionally define the Flight Control Computer (FCC) which also subscribes the pitch information to function properly.

Combined the system interface diagram looks like this:

Step #2: Data Normalization

While proceeding with the interface definition natural needs are coming up:

  1. In a system there is normally more than one device of the same type
  2. We do not like to define the same device twice
  3. In case of changes we prefer to introduce it only once for every device of the same type

One of the dBricks major features is the split between device definition and project definition. The device template describes the device as it would be off-the-shelf - independent of the project where it is used in. If you need to make changes in every device in any project it will be enough to update the device template only once.

Our example project uses numerous hardware devices of the same type: two ADIRUs.

In order for being able to use them in a normalized form we follow these steps:

  • Definition of a global device template which holds all general (reusable) definitions and properties
  • Introduction of several instances of this device template in our project
  • Linkage of these instances

The arrows in the picture show the relation between device templates and the devices in the project. Using the templates means that no new identity has been created. Every device is described only ONCE at ONE place.

Every project is an interface data model which is not a single entity. It is an object consisting of other objects which are linked with each other.

Step #3: Physical Interconnections Definition (Buses and Wires)

In the preliminary steps we have defined the data to be exchanged in our system. To complete the system definition we still need to describe:

  • The physical media used for the data transfer
  • How the data is coded within the data transfer (bus) - definition of data transfer (see step #4)

In order to do the physical interconnection the data model needs to hold additional entities:

  1. Device template: hardware ports
    • Hardware ports are optional device interfaces for physical interconnection to other devices
    • Hardware port properties include
      • Name
      • Bus type (ARINC429, 28VDC Power, MIL-STD…)
      • Direction (input, output, duplex)
  2. Device template: connectors with pins
    Each port can be allocated to connector contacts
  3. Project: hardware buses
    The hardware bus is a project level entity and interconnects hardware ports of instantiated devices.

Step #4: Definition of Data Transfer (Transport Layer)

Exchanging a parameter sounds simple. Nevertheless, there are many possibilities how this parameter can be transferred and how submitter and subscriber interpret it. In order to assure correct "understanding" on both sides it is important to define:

  • the transport layer which defines the transfer "service" (e.g. ARINC429)
  • the coding / decoding rules to insert the parameter value into the transfer service and get it out again

For the description of all necessary encoding/decoding details, we introduced an entity we call "port filling". It contains all specification information of how parameters are encoded/decoded and serve as a bridge between logical data transfer definition and physical connection. This entity is a part of the template description and therefore available for any instance generated from this template. Port filling objects can be assigned to one or several outputs or duplex hardware ports. This saves a lot of maintenance effort as it is usual that devices contain numerous similar output ports.

The port filling is protocol-specific, but it always contains a list of parameters to be transferred and explicit coding details.

See this example using the ARINC429 transport layer:
As you might know, A429 data exchange is composed of 32-bit words. These words are normally transferred on a regular basis with a predefined refresh rate that has to be defined. To distinguish one word from another the 8 start bits of each word contain labels. And finally, most of the parameters in A429 transfer are coded in fixed-point data format so we need to define the least significant bit, most significant bit value, and size.

Step #5: Retrospective and Conclusion

At this point we finalized:

  1. The definition of Device Templates including
    • Hardware ports
    • Port filling details
    • Assignment of port filling details to hardware port ==> Port filling to hardware port links
    • Functions and parameters
    • Assignment of parameters to port filling ==> Parameter to port filling link
    • Physical connector
    • Assignment of hardware port to physical connector ==> Hardware port to connector link
  2. The instantiation of devices in our project
    • 2x Air Data and Inertial Reference Unit (ADIRU)
    • 1x Display Unit (DU)
    • 1x Flight Control Computer (FCC)
  3. The exchange rules of our devices in our project
    • Hardware port links between the devices ==> Port interconnections
    • Parameter links within project ==> Parameter source / sink relation

The created structure provides us easy validation. We can assure consistency by checking that all defined parameter links contain the relevant encoding details and are supported by wiring design. This consistent structure is the perfect base for automatic checks and dBricks scores by performing these automatic checks.

Of course engineering in real-life brings up a lot of tricky features and exclusions. But what is an engineer without challenge? ;-)

The general idea stays always the same despite all exclusions:

  1. Define your actors
  2. Define the data they have to exchange
  3. Define the encoding
  4. Define the transfer service

Finally to stick up with dBricks:
Once you have achieved the interface data model dBricks will help you with lots of additional features to make your daily work easier. It provides data reports including formal documents like schematics or even a complete interface control document (ICD). It provides you non formal analytic reports that help you to design the best possible system.

Just check it yourself: Get Demo Access

P.S. Hereuder you can find some simplified data model diagrams related to each abovementioned step.

UML Diagram for step 1

UML Diagram for step 2

UML Diagram for step 3

UML Diagram for step 4

UML diagram for step 5

On our website we use technical, analytical, marketing and preference cookies. These are necessary for our site to work properly and to give us information about how our site is used.