Handling of array-like data types
Dynamically sized structures are not supported since they are forbidden in safety critical space applications. Instead, TASTE allows the specification of fixed sized arrays with ASN.1. But it is not possible to have two instances of the same array-like data type with different sizes.
Type Specialization: Whats currently posible
In ESROCOS we used as set of common base-types that were supposed to be used on the interfaces of re-usable interfaces, so that software components that are developed individually of each other are can be compatible, if they make use of the common data types.
ASN.1 allows to customize array type definitions by splitting the type specification into two parts: a) the re-usable base-types with a size- variable as a placeholder for the dimensionality of array-types, and b) an additional ASN.1 file containing the size-variable specifications.
While the base-types in a) are supposed to remain untouched by the user, the size-variable file is edited in a user project.
The problem with this approach is that it is only possible to give only one size per type. The result is that it is not possible to have components that use the re-usable data type with two different sizes.
Use-case example
Assume a robot with a mobile base composed from 12 joints and a manipulator with 6 joints. the drivers for boths subsystems should use the JointCommand data type, which is an array-like data structure with position, velocity and acceleration vectors. To both systems there is motion controller connected (one for the manipulation and one for the locomotion) producing the reference JointCommands for the respective subsystems.
While such a decomposition is common in robotics, it is impossible in TASTE, since the JointsCommand data type can only have on size. Effectively this hinders the development of re-usable components, if they use array-like data types on their external interfaces and the dimensions are first known, when the components get instantiated.
originator: Malte / DFKI