Composition of Items
Introduction
Purpose
This document contains the concept and definition to handle composite devices in ECLASS according to the ECLASS rules and regulation. The term ‘Composite Device’ will be defined, different discussed concepts to handle ‘Composite Devices’ will be delimited.
From a theoretical perspective all products are composites assembled from subcomponents. Even atoms can be divided. In practice the product data quality is driven by user’s requirement which defines the depth of details.
Scope
In Scope is
- Pointing out a lean way of setting up a composite device close to the current ECLASS concept, structure and capabilities and enabling ECLASS users to compose devices.
- Especially giving the ability to ECLASS users who are away from the industry sector and not familiar with AutomationML scenarios to build objects consisting of components made of other objects.
Out of Scope is
- The approach shall not be limited by current capabilities of the CAx tools.
- The usage of composite device structure will not be applied for ECLASS Basic users in the CSV export format.
- Former versions of ECLASS.
Expected improvements
Besides all discussed solutions to find possibilities for building composite devices the focus is to build up a method for composing devices which is strictly based on the existing structure and rules of ECLASS and giving ECLASS users a manageable opportunity to create composite devices
- without a high increase of generated data
- without allowing too fuzzy content
Although the final concept for composite devices does not require the change of ECLASS’ business rules in the first step, this has already been changed to allow the usage of APPLICATION CLASSES (ACs) within ACs including Cardinality and Polymorphism to derive ACs from ACs which was formerly not possible in the ECLASS Basic business rules but was allowed meanwhile in ECLASS Advanced.
Indeed ECLASS already contains Classes which are in fact aggregations of other existing Classes in ECLASS but without giving ECLASS users the opportunity to define a kind of relation between them. So, users currently have to decide what is their requirement and usage to take either the composite Class or just the list of parts (Classes) without an AC for the “composed main product” to be defined. To setup structure capabilities to define composite devices gives users the possibility to aggregate ECLASS classified products, its composition list (bill of material) and the specific relation type between each component and the composed product.
The new concept defines an ASPECT to handle compositions potentially inherited in every AC of ECLASS hierarchy and gives the opportunity to consider every AC being a “composed main product” with the mentioned list of components. This gives the capability of just relating content of every existing AC, without cascading ACs including their complete Property structure and even without the necessity to be itself again a “main product” of the inherited ACs.
The further discussed option of handling composite devices exactly focusing on this cascaded AC to one complete container with all inherited ACs, their specific PROPERTY(IES) and other STRUCTURE-ELEMENT, which was the preferred option of software manufacturers, will be further developed in the expert groups.
This document focuses on the flat Aspect version containing just the capability of giving every AC (“composed main product”) a list of components by a new Aspect.
Definitions, acronyms and abbreviations
composite device
composed Class formed by an aggregation of components.
component
part of a device described by an Application Class (AC).
Further definitions, acronyms, and abbreviations are described in the ECLASS Wiki (http://wiki.eclass.eu).
Basic assumptions
The following assumptions are made in this document:
ECLASS business rules and guides
- All current Aspects of the concept for composite devices do not contradict the ECLASS business rules and guides.
Documentation Wiki
- The concept gets documented in the ECLASS Wiki.
- The improvements stay conceptually in conformity with the ISO 13584-42/IEC 61360-2 data model.
ECLASS content
- The necessary new structure elements will be added to the next ECLASS RELEASE.
- All changes necessary for implementing the composite device concept do not influence the current ECLASS content beside the currently existing “Pseudo” composites that should be transformed into the new structure.
- The usage of composite devices is an optional offer for the different expert groups of ECLASS and the integration requires no immediate changes of the current structure of Classes, PROPERTY(IES), VALUE(S) etc. The composite device is described by a new additional ASPECT in every existing AC in ECLASS. Assembly information for the composite can be implemented later in the new entity “relation” in ECLASS.
ECLASS CDP (Content Development Platform)
- The concept of composite device based on a new Aspect requires no modifications of the CDP GUI to enable the usage of the new structures.
- The GUI presentation and behavior need only to be developed for the new entity “relations” in the CDP.
ECLASS Dictionary Exchange Formats
- The ECLASS XML and CSV do not have to be adapted regarding the implementation of composite devices.
ECLASS TUF
Still to be clarified: For which use cases would an automatic created TUF entry be possible and for which use cases TUF entries should be created manually in CDP?
References
ECLASS Release
More information on ECLASS can be found at ECLASS Releases
ISO 29002-5
Industrial automation systems and integration -- Exchange of characteristic data - Part 5: Identification scheme
Prerequisites
Status as-is in ECLASS
Current handling
As there is no model support or tool support for the creation of composite device or other relationships between Classes, composite devices are currently being described via Properties („battery“ or „battery-type“) but also through Class names like „valve (with drive)“.
To describe details of subordinated component Blocks are defined. E.g. a thermoelement is a component with its own article number. Its Properties are grouped in a BLOCK. This Block is used in the description of an APPLICATION CLASS(ES) associated with the Classification Class '27-20-02-08 Temperature measuring electrical complete'.
With the concept of component relations, a link to other components including other Properties is possible. This concept is integrated at different Aspects and Blocks of the ECLASS Advanced model.
Consequences
From ECLASS perspective there is a need to avoid duplicating Classes that are already existing within the ECLASS DICTIONARY and which need to be used multiple times due to variants. ECLASS wants to be able, in the context of Classes which are reused in several compositions, to extend, describe and exchange these Classes with the composite device method.
From the user perspective ECLASS users want, within the context of the ECLASS methodology, to build freely, to describe (Classes, Properties and Relations) and to exchange assemblies on basis of ECLASS.
Improving content quality
The opportunity to reduce duplications of similar content by improving the logical structure will generally improve the quality.
Market situation
Having a closer look at many products: they are already compositions of subproducts. An example is a fuse less load feeder which is a combination starter (IEC 60947-4-1:2018, 3.4.7) including a motor protection switching device MPSD (manually operated circuit breaker for motor load), a power contactor and a dedicated wiring device. The composition and all its components are distributed and therefore have their own product data descriptions using different APPLICATION CLASS(ES).
Actual complex products, like the example ADN550-008 Temperature measuring electrical complete' in Figure 6, are often composed of other in ECLASS defined products (ACs). An Application Class is either an end-product or a component that can be assembled to build a product with a structured model.
When it comes to build relations between components as described above, they can only be combined using exchange formats like AutomationML or software CAD systems that handles the assembling process. This type of ECLASS users that has the knowledge and the infrastructure to work in such a way belongs to a relatively small number of ECLASS Advanced users. All users that do not use AutomationML or similar formats are not able to build composite devices. An example for this is currently in ECLASS the expert group ‘24 Office product, facility and technic, papeterie’ with the Classification Class ‘24-39-01-01 POS display, merchandising unit, filled (office prod., facility, technic, papeterie)’. It is worth to mention that all products are compositions apart from raw materials.
Logical concept
Enhanced composition description
The current concept to build up composite device contains two submodels.
- The first submodel defines a composition of components to form a composed main product.
- The second submodel lists all relations between the composed main product and all components.
With the help of this composition modelling, a motor starter combination can be represented using both submodels.
Composition handling
The composition modelling always requires a ‘composed main product’ which must be an existing ECLASS AC to refer further Application Classes as component Classes. These AC identifiers are given in the composition model. For identifying the composed product and its components, unique identifiers are defined. Because the composed product and the components are mostly available separately on the market, each component has a Block of manufacturer identification and its Properties. Additionally, a relation to an existing ECLASS description of a component e.g. as a BMEcat file can be added.
This concept allows only one sublevel of components. If a component can be divided in further components, the component can have its own composition describing its components.
Most products are assembled from components. So, the concept of composition should be used by many Application Classes in ECLASS. Therefore, this new generic Block structure is suggested to be an ECLASS Aspect.
The Composition concept itself contains until now no information about how the components are assembled. It contains no information about their relations within the “composed main product” and the consisting components and neither between the components themselves.
Relation Information
The second submodel of the composite device concept defines how to handle the list of components and their combination.
In Figure 12 some relations between the main composed product and its components are depicted. These relations stand for electrical connections between conductor terminals. Further types of relations are possible. For example, relations between component holders (component receptacles) and mounting variants (fixing variants) are needed.
Including Application Class in an Application Class
In some use cases it might be useful to include component APPLICATION CLASS(ES) in another Application Class.
The component Blocks shown in Figure 14 can be replaced by existing Application Classes. The data of the component is stored in the data set of the main product instance. The component Blocks describing the ‘Temperature measurement connection head’ and ‘Thermowell’ are substituted by the existing Application Classes as components. It is a homogeneous dataset and not a datalink like in concept of composition.
Technical implementation
The Composition container “composed main product”
Aspect ‘Composition of components’
The technical structure to collect Composition in ECLASS will be a new Aspect called ‘Composition of components. Adding a new Aspect to a Class gives the ability to this Class of being a ‘composed main product’ containing any ‘components’. This enhancement is completely embedded extending every AC. All further AC related Properties of the ‘main product’ are inherited in the usual method. Properties of all components related ACs are not included as this is just a flat reference that can be queried by an additional call for the original related AC.
Aspect contains a Property ‘Product identifier’
For setting a reference to Properties of the composed main product and the components, an identifier ‘Product identifier’ (STRING) is introduced. It is essential that all identifiers are unique inside the description of the Composition.
Aspect contains a Property ‘Number of components’
The Property ‘Number of components’ is type INTEGER and is referred as a condition to a Cardinality for recurring components.
Aspect contains a Block ‘Component’
‘Component’ is a Block containing all Properties of a component.
Property ‘Application Class IRDI’
An ‘Application Class IRDI’ is necessary. It needs to be an existing AC in ECLASS. A STRING describes the IRDI of an AC referring to another AC.
An extension of the concept could be to use the Class reference type.
Property ‘Product identifier’
The definition of a ‘Product identifier’ (STRING) is necessary to refer later exactly to this part for the type of assembly connection. It may also help to distinguish components of one type with different usages.
Block ‘Manufacturer’
This Block is already defined in the ECLASS DICTIONARY within the Aspect ‘Identification’. It describes Properties important for ordering the product.
Property ‘source as path info’
To avoid adding product data twice a link to the ECLASS description of the component is used. This link ‘source as path info’ (STRING) can be an url or a filename with its path. While exchanging instance product data via a BMEcat file, the composition and all its com-ponents can be stored in one file. Then the string of the link is ‘../’.
Part assembly information
Additionally, to the raw list of components of a ‘composed main product’, the Aspect ‘Composition of components’ has the capability to handle a predefined list of connections called relations between the components.
Aspect contains a Property ‘Number of relations’
Similar to the Cardinality for the list of components inside the Aspect ‘Composition of components’ is the Cardinality ‘Number of relations’ between the components.
Aspect contains a Block ‘Relation’
The Block ‘Relation’ contains all Properties describing the relation between two components or between the composed end-product and any components.
Property ‘Type of relation’
The Property ‘Type of relation’ is defined on the basis of a fixed Value list which contains different relation type abilities like ‘wiring of connectors’, ‘Connection of fixing variants’ and furthermore. This Property defines the type of connection between ports of the composed main product and component or between two components. Sometimes a port of the composed main product is identical to a port of a component. Therefore, Values like ‘Identical connectors’ (“Same conductor Terminal”) and ‘Identical mechanical fixing variants’ (“Same mechanical mounting”) are dedicated to the Value List of the Property ‘Type of relation’ (Figure 16).
‘Relation’ Property ‘Product identifier’
With the Property ‘Product identifier’ a reference to the identifier in Block ‘Component’ is set.
‘Relation’ Property ‘Port identifier’
As also displayed in Figure 13 the component, pointed by its identifier, has potentially a defined number of ports to be connected. Like today’s concept of identifying ports in ECLASS by IDs and names, is it possible to connect any port from any component to another one.
Responsibility for extending the ECLASS content
New required Structure Elements
ECLASS Office is responsible for creating the required new STRUCTURE-ELEMENT(S).
Assignment of the new Structure Elements
Only the Expert groups are responsible for adding the new Structure Elements in their Classes.
Additional Example
Main product
Example 'Kitchen block'
Integrating different perspectives of supply chain roles ‘kitchens’ have already 3 product levels integrated in ECLASS:
- The ‘flattest’ option ‘Kitchen block’ simplifies the complex product to a manageable description by Properties for marketing.
- The next deeper level of configurable kitchens refers to each corpus of a combined kitchen block describing its functions and inside equipment.
- The deepest perspective for planning kitchens (lot size one) handles a corpus in parts to be flexible for customized versions of a standard model but is, nevertheless, also able to be described including functions and inner equipment.
Assembly ‘Kitchen block’
The kitchen block made off an arbitrary amount of corpus is an example for a composite device that can have endless variations, sizes and forms. This current concept of defining composite devices is capable to handle the necessary flexibility and to describe a customer order lot size one in an exact manner.
Assembly information
The current model is able to describe the kitchen assembling process including part integration, electrical connections for the large appliances and water/wastewater supplies.
Further Tasks
- Development of concept to enable and disable Aspect for the integration of AC in AC