Skip to main content

Concepts

Reference designation system (RDS) allows to designate the asset information uniquely. In AIH all business process data, signals and other IoT data can be linked to the asset system element they belong to via Designation, which has a unique code representation. This ensures that all asset information is always traceable.

Since assets of same type, e.g. wind turbines, may vary by design, AIH allows to configure all possible system designs and construct their system structure accordingly.

Aspects#

Aspect represent a point-of-view, when the configurator breaks down the asset into sub-definitions. Below are some guiding questions to understand product, location and function aspects. Product aspect: how is the system physically put together? Location aspect: where in the turbine is the system located? Function aspect: what function does the system carry? Type aspect: what specific type does the system belong to?

There are 4 default aspects, when AIH is installed:

  • Function - To be able to break down the asset with respect to its function
  • Product - To be able to break down the asset with respect to the components (products)
  • Location - To be able to break down the locations in the asset
  • Type - To be able to break down the asset with respect to its type

Applier languages#

Applier languages represent mapping tables from your company's designation to another "language". Things like external suppliers, service providers might call functions by another name and code. The applier language lets you map to/from a "foreign language".

Schema#

A schema serves as a comprehensive repository of codes pertaining to system and component classes. Each schema node is comprised of a name, code, definition, and examples. Schema nodes are used when creating structures, with each structure node referencing a specific schema node. The intention is to align code definitions across various structures, thereby enhancing coherence throughout the system. Schemas analyse component classes and are fully configurable. Each schema is versioned and is with lifecycle status to make sure changes are tracked in the system.

Structure#

A structure can be visualized as a tree, with a central function or location from which it branches into sub-structures.

Designation structures/hierarchy trees attain an aspect. The objective is to create precise structures for assets with predefined characteristics, utilizing pre-existing codes from published schemas.

Key Features:

  • Customizable Aspects: You can change the aspect of structures.
  • Grouping with Structure Groups: You can group similar structures together for a clear view.
  • Applier Language Assignments: You can give names to different nodes of the structure in different languages, making it easier for everyone to understand.
  • Versioning and Lifecycle: Each structure has different versions and statuses, so you can track changes and make sure everything stays connected, even when things are updated.

Example (function): Energy conversion system. This is a function that converts one type of energy (e.g. wind) into another type of energy (e.g. electricity). To carry out this function, the function carries out a set of "sub-functions"; e.g. power generation system, drive train system etc.

Each of these sub-functions, in turn, has their own sub-functions.

Example (location): Wind turbine generator can be divided into sub-locations: Platform, Nacelle, Tower. Each of these sub-locations, can be further divided into e.g. Nacelle-front, Nacelle-back, Tower-top, Tower-mid, Tower-lower.

Applier Designation#

Applier Designation is the part of structure node information model. On each node in the structure, the configurator can add applier-code and denomination for each applier language. See Applier langauges for more info.

Design#

A design encompasses a collection of components, represented by design objects, within a specific type of asset.

It is important to establish a link between designs and structures. This connection is needed for utilizing structure nodes within design objects to leverage object positions, functions, and more.

Design object#

The design object represents a component in an asset. For classifying design object with codes the design object should be referenced to structure nodes. Each design object can reference one or more structure nodes to specify its aspect as function, location etc. An object is often representing a physical existence.

Each design has different versions and statuses, so you can track changes and make sure everything stays connected, even when things are updated.

Parameters#

Parameters represent optional components or features within design. The options are only installed on some main systems, but the design is still the same. Here's how it works:

Setting Parameters: The design configurator begins by defining a set of important parameters.

Conditional Design Objects: With the parameters in design, the configurator can now make certain design objects conditional. This means that these objects exist based on the parameters existance.

Parameter Values: The values of these parameters are set when a design is used for a specific main system. This flexibility allows you to tailor designs to suit different needs without redesigning everything from scratch.

Example: Siemens D3 can be built in different types of climate; cold, hot, rainy etc. De-icing systems are usually only installed on the turbines in the cold regions. This means that the Design D3 has a slight variance depending on the region. The configurator can add a parameter to the design: "De-icing". Then configurator assigns the relevant design objects (those that are related to the de-icing system) to the de-icing parameter. When an asset manager assigns the Siemens D3 design to a turbine, then he/she can choose whether the turbine has that option installed.