pseudo_dynamic_data_types

Problem Description

To lead into the problem description, we start with two statements

1. Within ESROCOS compatibility between different software modules is established by a set of common data types.
2. The use of TASTE imposes a constraint, that all data types used within an application must be statically allocated.

In some cases these two statements seem difficult to hold in a multi-project framework: Imagine a software developer who wants to create a component which applies an image processing algorithm to a input image which can originate from more or less arbitrary cameras. the algorithm itself has no constraints for resolution of the input images. The actual resolution of the data type will only be determined, when the software in integrated with a particular camera, which has be chosen as image source. The question is: how can the software developer write his component and still maintain compatibility to different sensors with different resolutions?

Our Approach

We approach this problem by splitting the type specification into two parts:

1. The base-type which is shared between all software projects

-- In Frame.asn
-- Reference to project-individual file, specifying size attributes for pseudo-dynamic data types
IMPORTS
frameMaxBytes, frameMaxAttributes FROM FrameConfig   -- FrameConfig.asn is an external file provided at build time

-- The 'flexible' type with size properties not yet fully specified
Frame-Parametrizable{T-Uint32: maxBytes, T-Uint16: maxAttributes}   ::=
SEQUENCE
{
     timestamp           Time,
     image               OCTET STRING (SIZE(0..maxBytes)),
     attributes          SEQUENCE (SIZE(0..maxAttributes)) OF Sample-attribute-t
    -- ...
}

-- The instantiated type, accessible from the Interface View and from the component library
-- This is the type which is used within the different projects
Frame ::= Frame-Parametrizable{ frameMaxBytes, frameMaxAttributes }

2. The project-individual size attributes file, which contains size attribiutes for array-like strufctures of unspecified size in the base-types

frameMaxBytes INTEGER ::= 307200
frameMaxAttributes INTEGER ::= 10

The component developer would create a FrameConfig.asn and use it for the development of the algorithm/driver. This file would be passed as parameter/dependency to the build.

The application developer would create his own FrameConfig.asn and:

• Build the component library (algorithm, driver) with this new configuration file
• Build the TASTE application also with this configuration file (by passing it to the taste-update-data-view command).

This approach allows using parametrized ASN.1 data types in library components and TASTE models without changing the source code of any of them, just by passing the FrameConfig.asn file as a parameter or dependency to the build and recompiling everything, which is trivial with autoproj.

Limitations

The main limitation is that you cannot have two Frame types, in different parts of the system, with different sizes.