< PreviousField Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 49 of 67 On the other hand, EDDL defines a set of language constructs that are used to describe industrial field devices. Each construct supports its own set of attributes and references. EDD information adds semantic contents to the raw data values read from and written to the field devices. The primary objective of the EDDL-OPC UA information model is to describe the correspondence between the OPC UA Object Model elements and the EDDL elements when an EDD is used to populate the FDI Server with Objects. Completely meeting this objective means dealing both with enhanced data access through OPC UA and with UI interactions between OPC UA clients and servers. 15.2 Localization Localized text In various definitions, EDDs may contain information in multiple language variants. Examples are the LABEL and HELP attributes. The server has to select the proper language for each client as follows: When creating an OPC UA Session, the OPC UA Client passes the locale(s) that it requests to be used for all services within this Session. If the Server does not support any of the requested locales it chooses an appropriate default locale. Engineering units Variables with a UNIT CODE are represented in OPC UA as AnalogItem Variables. The UNIT CODE is exposed via the EngineeringUnit Property. Changing the EngineeringUnit will cause all EDD Variables that depend on the associated UNIT CODE to be recalculated. As a result the OPC UA Variable values will be set as well. Changing the EngineeringUnit will affect all Clients. 15.3 Device General Subclause 15.3 specifies the mapping of FDI Package elements to Device Types and Device Instances. Devices may also have Blocks (see 15.4). Mapping to Attributes to a specific DeviceType Node The BrowseName and NodeId Attributes are vendor specific. The DisplayName Attribute is created from the Package Catalog: DeviceType.Name. The Description Attribute of a Device is information that serves to further identify, manage, locate, and/or explain the device whose contents are defined by the user. For purely block-oriented devices this will appear only on blocks. For example, in HART the MESSAGE variable can be used here. Mapping to Properties Type and instances share the same Properties. Some of the Properties are created from information in the Package Catalog. Table 48 specifies the mapping of Properties to Package Catalog elements. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 50 of 67 Table 48 – DeviceType Property Mapping Property Package Catalog element Manufacturer ManufacturerName Model ListOfDeviceTypes[i].ListOfInterfaces[j].DeviceModel. DeviceRevision ListOfDeviceTypes[i]. ListOfInterfaces[j].Version. FDITechnologyVersion FDITechnologyVersion. The SerialNumber, RevisionCounter, SoftwareRevision, and HardwareRevision Properties correspond to the value of the protocol-specific “serial number”, “revision counter”, “software revision”, and “hardware revision” Parameters, respectively. The DeviceManual Property is an empty string. Documents can be found in the attachment set. If a Picture element is available in the FDI Package it can be mapped to the OPC UA Icon Property (see IEC 62541- 3). If multiple resolutions are available the host has to choose. Mapping to ParameterSet Some devices are strictly block-oriented with no kinds of Variables on the device-level. Mapping an EDD for these devices will result in an empty ParameterSet. When VARIABLE, VALUE_ARRAY or LIST items exist on the device-level, the resulting Parameters are kept in the “ParameterSet” as a flat list of Parameters. FunctionalGroups reflect the structure of the device menus defined in the device’s EDD. A ParameterSet with all Parameters exists on the Type, the offline and the online instances. See 15.6 on how EDDL attributes are used to create Parameter nodes. Mapping to Functional Groups The top-level Functional Groups that are referenced directly from the Device Object correspond to the root MENU items as defined in FCG TS61804-4. Naming conventions are used to differentiate between Functional Groups for handheld and for PC-based applications. There are no Functional Groups on the DeviceType. Mapping to DeviceTypeImage The Variables in the DeviceTypeImage folder are created from the Package Catalog: DeviceTypes[i].ListOfDeviceImages. BrowseName and DisplayName represent the file name from the Relationship Type. Mapping to Documentation The Variables in the Documentation folder are created from the Package Catalog: DeviceTypes[i].ListOfDocuments. BrowseName and DisplayName represent the file name from the Relationship Type. Mapping to ProtocolSupport The Variables in the ProtocolSupport folder are created from the Package Catalog: DeviceTypes[i].ListOfInterfaces[j].ListOfCommunicationProfileSupportFiles. BrowseName and DisplayName represent the file name from the Relationship Type. Mapping to ImageSet The ImageSet contains Variable Nodes for all images from the EDD that are needed for UIDs. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 51 of 67 Mapping to ActionSet The ActionSet references OPC UA Objects that represent all EDD Methods except for the abort and the action methods as defined in FCG TS61804-3. See 15.8 on how EDDL attributes are used to create Action Nodes Mapping to MethodSet The MethodSet (inherited from IEC 62541-100) is not used by the FDI. 15.4 Modular Device Subclause 15.4 specifies the mapping of a modular device’s package. As described in FCG TS62769-4, a package for a modular device contains a head station EDD and one or more module EDDs. The head station EDD contains COMPONENT constructs that identify the module EDDs. The EDDs for head station Device and for each module shall be individually mapped according to the mapping rules for single Devices. The head station Device will show up as a modular Device as specified in IEC 62541-100. • The SubDevices component in the instance of the head Device references instantiated modules. • The SupportedTypes folder in the SubDevices component references all DeviceTypes for modules that may appear in the instance of the head Device. 15.5 Block General Subclause 15.5 specifies the mapping of EDDL elements to Block Types and instances. EDDL supports the definition of devices that are block-oriented, and devices that are non-block oriented. When blocks (specifically, Block_A) exist in an EDD, the resulting device shall be modelled as block-oriented Device as specified in IEC 62541-100. The Block node instances are kept in the Blocks component. A Device that does not support EDDL defined Blocks will not have the Blocks component. The SupportedTypes folder in the Blocks component of a DeviceType references all BlockTypes that may appear in a Device Instance. The Blocks component in a Device Instance references instantiated Blocks. Mapping to Attributes The BrowseName and DisplayName correspond to the EDD Identifier and LABEL Attribute of the corresponding EDDL Block, respectively. The NodeId is vendor specific. The Help attribute of the corresponding EDDL Block is mapped to the Description attribute of the Block instance node. Bad_AttributeIdInvalid shall be used if EDD contains no Help. Mapping to ParameterSet All VARIABLE, VALUE_ARRAY, LIST items specified for a Block are used as Parameters in the “ParameterSet”. A ParameterSet with all Parameters exist on the Type, the offline and the online instances. See 15.6 on how EDDL attributes are used to create Parameter nodes. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 52 of 67 Mapping to Functional Groups A Block may have FunctionalGroups that expose its Parameters in an organized fashion, reflecting the structure of the block menus defined in the device’s EDD. The top-level Functional Groups that are referenced directly from the Block Object correspond to the root MENU items as defined in FCG TS61804-4. Naming conventions are used to differentiate between Functional Groups for handheld and for PC-based applications The BrowseName of a FunctionalGroup is the EDD identifier of the corresponding EDDL MENU or COLLECTION. There are no Functional Groups on the BlockType. Mapping to ActionSet The ActionSet references OPC UA Objects that represent all EDD Methods defined for a specific BLOCK except for the abort and the action methods as defined in FCG TS61804-3. See 15.8 on how EDDL attributes are used to create Action Nodes Mapping to MethodSet The MethodSet (inherited from IEC 62541-100) is not used by the FDI. Instantiation rules The BrowseName of a Block is generated by the FDI Server from the EDD identifier of the corresponding EDDL BLOCK_A by adding a numeric suffix that the OPC UA server generates in order to make the BrowseName unique. For example, __analog_input_0, __analog_input_1, __pid_control_0. The DisplayName of a BLOCK_B Block is the LABEL attribute. The DisplayName of a BLOCK_A Block is defined in the protocol annex. The Description of a Block is the HELP attribute of the corresponding EDDL BLOCK. Bad_AttributeIdInvalid shall be used if the EDD contains no Help. 15.6 Parameter General EDDL Parameters (for devices or blocks) are mapped to OPC UA Variables. The VariableType used may be of any sub-type of the abstract BaseVariableType. In most cases they will be mapped to the VariableTypes defined in IEC 62541-8, for example, DataItemType, AnalogItemType or DiscreteItemType. This standard includes additional VariableTypes for more sophisticated EDDL types. See Table 50 for the mapping of EDDL types. The BrowseName of a Parameter is the EDD identifier of the corresponding EDDL VARIABLE, RECORD or VALUE_ARRAY. The DisplayName of a Parameter is the LABEL attribute of the corresponding EDDL VARIABLE, RECORD or VALUE_ARRAY. The Description of a Parameter is the HELP attribute of the corresponding EDDL VARIABLE, RECORD or VALUE_ARRAY. Bad_AttributeIdInvalid shall be used if the EDD contains no Help. Parameters have also a set of Attributes that are common to all VariableTypes. Table 49 summarizes the Variable Attributes and describes how they are set from the EDDL description information. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 53 of 67 Table 49 – Setting OPC UA Variable Attributes from EDDL variable attributes Attributes Description Value The most recent value of the Variable that the FDI Server has read from the device. DataType The EDDL data type is translated into an OPC UA standard data type according to Table 50. ValueRank Either set to “Scalar” or – when the Parameter is an array – the number of dimensions. ArrayDimensions Specifies the length of each dimension if the Parameter is an array. This attribute is not exposed if the length is unknown or dynamic. AccessLevel The AccessLevel Attribute is set based on the EDDL variable HANDLING attribute according to the following table: If the HANDLING attribute is missing, the Parameter will be defined as readable and writeable. Field Bit Description CurrentRead 0 Set if EDDL variable HANDLING is defined as READ. Reset otherwise. CurrentWrite 1 Set if EDDL variable HANDLING is defined as WRITE. Reset otherwise. UserAccessLevel The AccessLevel with possible restrictions based on client identity as defined by the FDI Server. MinimumSamplingInterval The MinimumSamplingInterval Attribute indicates how fast the FDI Server can reasonably sample the value for changes. It is suggested that the FDI Server checks the variable CLASS attribute to differentiate static variables from dynamic variables regarding the sampling interval. Static variables might be sampled only once and then only when the RevisionCounter changes. For static variables the FDI Server can use the MinimumSamplingInterval -1 (indeterminate). The Value Attribute is the Parameter value, and – for the online representation – reflects the device data value. The DataType Attribute is an OPC UA DataType chosen to match the EDDL type and size. Table 50 shows the correspondence between the EDDL types and sizes and the OPC UA VariableTypes and standard DataTypes. Table 50 – Correspondence between EDDL and OPC UA standard data types EDDL Data Type OPC UA VariableType OPC UA DataType Constraints Arithmetic INTEGER BaseDataVariableType, AnalogItemType SByte When the size specified in EDDL is 1 byte. Int16 When the size specified in EDDL is 2 bytes. Int32 When the size specified in EDDL is 3 or 4 bytes. Int64 When the size specified in EDDL is 5, 6, 7 or 8 bytes. UNSIGNED_INTEGER BaseDataVariableType, AnalogItemType Byte When the size specified in EDDL is 1 byte. UInt16 When the size specified in EDDL is 2 bytes. UInt32 When the size specified in EDDL is 3 or 4 bytes. UInt64 When the size specified in EDDL is 5, 6, 7 or 8 bytes. DOUBLE BaseDataVariableType, AnalogItemType Double FLOAT BaseDataVariableType, AnalogItemType Float ENUMERATED See 15.6.5 Byte When the size specified in EDDL is 1 byte. UInt16 When the size specified in EDDL is 2 bytes. UInt32 When the size specified in EDDL is 3 or 4 bytes. UInt64 When the size specified in EDDL is 5, 6, 7 or 8 bytes. BIT_ENUMERATED See 15.6.6 Byte When the size specified in EDDL is 1 byte. UInt16 When the size specified in EDDL is 2 bytes. UInt32 When the size specified in EDDL is 3 or 4 bytes. UInt64 When the size specified in EDDL is 5, 6, 7 or 8 bytes. Date-and-Time DATE BaseDataVariableType UtcTime The data type DATE consists of a calendar date. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 54 of 67 EDDL Data Type OPC UA VariableType OPC UA DataType Constraints (a 64-bit signed integer which represents the number of 100 nanosecond intervals since January 1, 1601 (UTC)) This data type has special codification in the device. Conversion to UtcTime is necessary when reading it from the device. Conversion back to DATE is necessary when writing it to the device. On write, if invalid data is written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the data. DATE_AND_TIME BaseDataVariableType UtcTime The data type DATE_AND_TIME consists of a calendar date and a time. This data type has special codification in the device. Conversion to UtcTime is necessary when reading it from the device. Conversion back to DATE_AND_TIME is necessary when writing it to the device. On writing if invalid data is written the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the data. DURATION BaseDataVariableType Duration (a Double that defines an interval of time in milliseconds (fractions can be used to define sub-millisecond values)) The DURATION data type is a time difference that consists of a time in milliseconds and an optional day count. This data type has special codification in the device. Conversion to Time is necessary when reading it from the device. Conversion back to DURATION is necessary when writing it to the device. On writing, if invalid data is written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the data. The OPC Duration type is limited to approximately 49,7 days, which is less than the theoretical maximum of the EDDL DURATION type. If the DURATION exceeds the OPC maximum the quality should be set to indicate this condition. TIME BaseDataVariableType UtcTime The TIME data type consists of a time and an optional date. This data type has special codification in the device. Conversion to UtcTime is necessary when reading it from the device. Conversion back to TIME is necessary when writing it to the device. On writing, if invalid data is written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the data. TIME_VALUE[4] BaseDataVariableType Duration TIME_VALUE is the “number of 1/32 ms”. The “Duration” is calculated by multiplying the TIME_VALUE with 0.03125 (which is the float equivalent for 1/32 ms). TIME_VALUE[8] BaseDataVariableType UtcTime The data type TIME_VALUE is used to represent date and time in the required precision for application clock synchronization. This data type has special codification in the device. Conversion to UtcTime is necessary when reading it from the device. Conversion back to TIME_VALUE is necessary when writing it to the device. On writing, if invalid data is written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the data. String ASCII BaseDataVariableType String Conversion to String is necessary when reading it from the device. Conversion back to ASCII is necessary when writing it to the device. On writing,if invalid characters are written, the service returns an appropriate error in the Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 55 of 67 EDDL Data Type OPC UA VariableType OPC UA DataType Constraints serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the string. BIT_STRING BaseDataVariableType ByteString Conversion to ByteString is necessary when reading it from the device. Conversion back to BIT_STRING is necessary when writing it to the device. On writing, if invalid characters are written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the string. EUC BaseDataVariableType String Conversion to String is necessary when reading it from the device. Conversion back to EUC is necessary when writing it to the device. On writing, if invalid characters are written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the string. PACKED_ASCII BaseDataVariableType String Conversion to String is necessary when reading it from the device. Conversion back to PACKED_ASCII is necessary when writing it to the device. On writing, if invalid characters are written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the string. PASSWORD BaseDataVariableType String Conversion to String is necessary when reading it from the device. FDI Servers shall allow PASSWORD Variables to be read only when a secure OPC UA channel has been created, i.e., a channel with encryption. VISIBLE BaseDataVariableType String Conversion to String is necessary when reading it from the device. Conversion back to VISIBLE is necessary when writing it to the device. On writeing,if invalid characters are written, the service returns an appropriate error in the serviceResult and the diagnosticInfo data members of the ResponseHeader and does not accept the string. OCTET BaseDataVariableType ByteString INDEX see 15.6.5 String BOOLEAN BaseDataVariableType Boolean As Table 50 shows, EDDL supports a variety of variable types. While that table shows the correspondence between the EDDL data types and the OPC UA VariableType, it does not provide any details on how other EDDL VARIABLE TYPE construct attributes are supported. It does not provide any details on how other OPC UA BaseDataVariableType attributes should be set either. Subclause15.6 is intended to provide details for each EDDL data type. Private Parameters The Parameters specified in an FDI Package may be declared private using the PRIVATE Attribute specified in FCG TS61804-3. The FDI Server shall create Nodes in the Information Model for the private Parameters but they shall not be browsable. The FDI Server shall return the NodeIds of private Parameters when the name of such a Parameter is passed to TranslateBrowsePathsToNodeIds (the startingNode argument shall be the “ParameterSet” Object). Once the FDI Client has obtained the NodeId all Service requests for private Parameters will be processed in the same way as for public (browsable) Parameters. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 56 of 67 An example of private parameters is parameters that should only be modified through an Action. These parameters should not be visible to FDI Clients to prevent direct access. FDI Clients invoke Actions to access these private parameters. MIN_Value and MAX_Value If one or more MIN_VALUE and MAX_VALUE attributes are specified for a variable in EDDL they shall be mapped to the Min_Max_Values Properties defined in 10.3. Engineering units The EngineeringUnits Property defined in IEC 62541-3 and IEC 62541-8 shall be used: • If the variable has the CONSTANT_UNIT defined for itself in EDDL. In this case the EngineeringUnits Property keeps the EDD CONSTANT_UNIT variable attribute. The FDI Server shall deal with the fact that CONSTANT_UNIT can be conditional. • If the variable is involved in an EDD UNIT relation it is the FDI Server’s responsibility to implement the unit code update mechanism. An EDD UNIT relation specifies a reference to a variable holding a unit code and a list of dependent variables. When the variable holding the unit code is modified, the list of effected variables using that unit code shall be refreshed. When an effected variable is displayed, the value of its unit code shall also be displayed. The standard OPC UA notifications can be used to report to the FDI Clients that the unit code changed. Enumerated Parameters If no semantic map has been applied to an enumerated variable, an OPC UA DataVariable with the VariableType MultiStateValueDiscreteType (defined in IEC 62541-8) is used for each enumerator in the EDDL enumerated variable definition – otherwise the VariableType MultiStateDictionaryEntryDiscreteType shall be used. The Value Attribute of the DataVariable is the numeric value of the state, and corresponds to the value attribute of the EDDL ENUMERATED TYPE. The ValueAsText Property of the DataVariable exposes the display value of the state, which corresponds to the description attribute of the EDDL ENUMERATED TYPE. The EnumValues Property of the DataVariable contains the complete list of enumerations, i.e., a table where each element is a structure consisting of EDDL ENUMERATED TYPE attributes “value”, “description”, and “help”. If no help attribute exists in the EDD, the value of the description attribute will also be used for this purpose. Bit-enumerated Parameters A DataVariable of OPC UA OptionSet VariableType is used for each EDDL BIT ENUMERATED VARIABLE definition. The OPC UA DataType is an array of Boolean where one Boolean is used per bit in the EDDL BIT_ENUMERATED VARIABLE definition. The Boolean array of the DataVariable reflects the status of all bits. TRUE is used when a bit is set and FALSE when a bit is reset. The EnumValues Property of the DataVariable contains the complete list of bit enumerations, i.e., a table where each element is a structure consisting of EDDL BIT ENUMERATED TYPE attributes “bit position”, “description”, and “help”. If no help attribute exists in the EDD, the value of the description attribute will also be used for this purpose. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 57 of 67 Representation of records A complex DataVariable is used to represent EDDL RECORD Parameters. The root DataVariable represents the record itself. It will have component DataVariables that represent the EDDL RECORD MEMBERS. (The MEMBERS of an EDDL RECORD are defined in EDDL by means of a reference to an EDDL VARIABLE.). See Figure 21 for an example of how records are represented in the OPC UA AddressSpace. BaseDataVariableType: Param_A PARAMETERS { Param_A, rec1 ; Param_B, rec2 ; … RECORD rec1 { LABEL "Rec"; MEMBERS { X, x_member; Y, y_member; } } VARIABLE x_member { LABEL "X"; TYPE FLOAT; HANDLING READ; } VARIABLE y_member { LABEL "Y"; TYPE ENUM (1); HANDLING WRITE; } … X (AccessLevel=CurrentRead) Y (AccessLevel=CurrentWrite) BaseDataVariableType: Param_B X (AccessLevel=CurrentRead) Y (AccessLevel=CurrentWrite) RECORD rec2 { LABEL "Rec"; MEMBERS { X, x_member; Y, y_member; } } VARIABLE x_member { LABEL "X"; TYPE FLOAT; HANDLING READ; } VARIABLE y_member { LABEL "Y"; TYPE ENUM (1); HANDLING WRITE; } Figure 21 – Example: Complex variable representing a RECORD BrowseName and DisplayName of the root DataVariable are set to the EDD identifier of the EDDL VARIABLE that implements this RECORD type. The DataType Attribute of the “root” DataVariable is BaseDataType. The ValueRank Attribute is used to specify that the value contains an array. The Value Attribute represents the values of all members in the order as defined for the RECORD. According to the example in Figure 21, the first variant will contain a floating point value and the second will be a numeric value representing the Enumeration. For each component DataVariable that represents an EDDL RECORD MEMBER: • The BrowseName is the identifier of the corresponding EDDL VARIABLE. • The DisplayName is the LABEL attribute of the corresponding EDDL VARIABLE. • The Description is the HELP attribute of the corresponding EDDL VARIABLE. Bad_AttributeIdInvalid shall be used if the EDD contains no Help. • The AccessLevel is derived from the HANDLING attribute. Readable and Writeable shall be used if the EDD contains no HANDLING attribute. Representation of arrays, and lists of Parameters with simple data types A single DataVariable will represent an EDDL VALUE_ARRAY or LIST item when the data type of the referenced array element has a simple data type. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 58 of 67 The OPC UA DataVariable Attributes are set as follows: • DataType is set to the type of the array element (see Table 50 for the data type mapping). • The ValueRank Attribute is used to specify that the value contains an array. In case of an EDDL VALUE_ARRAY the number of elements is exposed in the ArrayDimensions Attribute. In the case of an EDDL LIST the ArrayDimensions Attribute is not exposed. The number of elements is unspecific since the size can change dynamically. Representation of values arrays, and lists of RECORD Parameters Value arrays or lists of non-simple data types will be represented as OPC UA array of complex variables. Figure 22 shows the EDDL sample code of a VALUE_ARRAY of RECORDs and the corresponding complex variable in the OPC UA AddressSpace. BaseDataVariableType v_arr va_elem_rec_1 va_elem_rec_2 X Y X Y Figure 22 – Complex variable representing a VALUE_ARRAY of RECORDs In the FDI Server AddressSpace a complex DataVariable is used to represent the entire VALUE_ARRAY. Each VALUE_ARRAY element, which is in fact a RECORD, is represented as a component complex DataVariable. The RECORD MEMBERS are also represented as component DataVariables. The FDI Client refers to the X member of the first record in the array through the BrowseName v_arr.va_elem_1.x_member. Note that the index always begins with ‘1’. The DataType Attribute of all complex root DataVariables is BaseDataType. The ValueRank Attribute is used to specify that the value contains an array. The Value Attribute represents all VALUE_ARRAY entries. The first element corresponds to the first array entry and so on. Each element in turn contains an array. This may either be an array of simple types or an array of BaseDataType. A RECORD is always represented as an array of BaseDataType. Representation of COLLECTION and REFERENCE ARRAY The EDDL constructs COLLECTION and REFERENCE ARRAY are mapped to Functional Group Objects (see 15.7) when used for grouping only. Next >