When and Why Should I Start Using dBricks

1

There are more than one person working with Interface Control Document (ICD) data

Having a single source of up-to-date information is very advantageous and time-saving. Several users access simultaneously the ICD Management tool server both for reading and editing from any location in the world. Users with various specializations work on their relevant parts of the data model simultaneously. System engineers can trace all ICD aspects immediately from each sensor to the final acting device.

2

The amount of links increases the complexity excessively

System design complexity grows exponentially with an increasing amount of links as well logical as physical. When you are dealing with small ICDs composed of tens of hardware links and up to a hundred parameter links complexity stays adequate. But that is not necessarily reality!

Real-life ICDs of modern systems face the fact that even simple and well-defined devices like ADIRUs (air data and inertial reference units) use more than 300 output parameters per unit.

Provided that you:

• utilise various of these units for redundancy needs and
• each parameter links several times (e.g. to display system, flight control system, emergency recording system etc.)

the effort to handle all the data arises significantly. The importance of proper tooling becomes clear.

3

We plan to reuse ICD data in test rigs or for training devices configuration

dBricks provides the data export to various formats including machine-readable datasets used e.g. by training devices and/or test rigs. This feature avoids effort and benefits you by eliminating manually induced mistakes.

4

We plan to use model-in-the-loop testing for rapid prototyping

Rapid prototyping of an entire system includes the simulation of links between devices.

It is not unusual to find up to hundreds of thousands(!) parameter links in completed models.

Without proper means it becomes almost impossible to maintain the transfer of relevant ICD data to model environments.

5

We have several projects reusing components from others

OR

Our projects use components redundantly

One of the dBricks key features is the normalized data model.

As a result, any device related descriptions are saved only once in so-called 'templates'.

All projects utilize devices as an instance of the relevant device template.

Thus, as you have your device template completed you can incorporate it unlimited in all your projects.

Any template change will be traced automatically in all affected projects.

6

Our project maintains numerous options

Combinations of various options can result in an enormous number of possible configurations. The complexity and therefore the effort of configuration control arise exponentially. (E.g. if you plan 10 independent options, which is quite usual, you will end in 1024 (2^10) possible configurations)

Even if you do not take variants into account it is highly likely that will end in deviations for your prototypes and/or your rig and system design.

dBricks provides a very smart feature to handle options growth in an innovative and handy way.

7

We suffer from the lack of integrity between logical/transport/physical layers of our system design

dBricks provides a single integral data model that describes all aspects of the ICDs:

1. Logical layer: Data parameter links
2. Transport layer: Explicit data bus coding details of logical links
3. Physical layer: Wiring and connector description to implement the real connection of existing logical links.

This approach guarantees data integrity between all layers of ICD data.