Skip to main content
Version: Next

Architecture

Behaviour Twin KIT -- Remaining useful Life banner

Behaviour Twin KIT -- Remaining useful Life

BASIC ARCHITECTURE​

OVERVIEW​

An external consumer wants to know the remaining useful life of its component (e.g. a vehicle). It uses a RuL Consuming App (e.g. with a web interface) for this. At the data provider (likely an OEM), usage data is collected continuously with the consent and on behalf of the consumer. The usage history and all dependent components that can provide RuL values are known on the data provider's side. The data provider itself doesn't even have to know which components can provide RuL services/values. Its registed suppliers provide that information in their catalogs which are synchronized periodically. The data provider only must bind the usage data to the knowledge graph.

This approach is not limited only to OEMs and vehicles. Any system that provides usage data can utilize this approach, like tools/machines, production lines, building facilities, vending machines, computers, roads and so on.

ROLES​

Each participant in the Remaining useful Life (RuL) Behaviour Twin use case applies to one or more of the following roles:

  • RuL consumer (result requester)
  • skill provider (which is also the RuL consumer, provider of the use case logic)
  • data provider (OEM, provider of usage data)
  • RuL service provider (a component supplier, e.g. for gearboxes)

One of the special cases would be that the data provider is also the RuL consumer and/or RuL service provider and/or skill provider.

DETAILED ARCHITECTURE​

BUSINESS PROCESS​

For better readability, it is assumed on this page that the data provider is always an OEM/vehicle manufacturer.

The first addressee of a RuL skill must be the OEM since it has access to its suppliers who can provide RuL values.

business-process

  1. sync federated catalog:
    The federated catalogs are synchronized periodically. As a result, the OEM can resolve RuL prognosis function assets that are located at the supplier.

  2. Invoke RuL skill:
    The consumer invokes the skill by calling the agents API at its own EDC connector (ad hoc or as predefined asset). The OEM's EDC connector address must be known. Resolving this address is up to the consumer. The vehicle ID (VIN) is set as parameter for the skill.

  3. Delegate sub-skill:
    The skill is delegated to the OEM via EDC connectors.

  4. Resolve vehicle part of interest:
    The Knowledge Agent resolves the vehicle part for which the RuL value should be calculated.

  5. Resolve load data assets:
    The Knowledge Agent resolves the usage data asset for the vehicle part of interest.

  6. Resolve RuL prognosis function assets:
    The Knowledge Agent resolves all prognosis function assets from the federated catalog with type RemainingUsefulLife and the correct input type of load spectra. This type is infered by the usage data asset.

  7. Fetch load data:
    The data (parameters for the RuL prognosis functions) are fetched from the data provider's bound data source. They are translated into graph representation by a provisioning agent (data binding agent).

  8. Transfer load data and deploy sub-skill:
    The fetched data and a sub-skill (logic for calling the RuL calculation service) are transferred to the RuL calculation service provider's Knowledge Agent via EDC connectors.

  9. Call service and fetch RuL result:
    The RuL calculation service (prognosis function) is called. The data (parameters) are translated into the format the service requires. This is automatically done by an remoting agent (service binding agent), which is statically configured by service bindings. The result of the service then is translated back into graph representation by the remoting agent.

  10. Return RuL result:
    The result is transferred to the OEM via EDC connectors.

  11. Delegate RuL result:
    The result is delegated to the consumer via EDC connectors.

To have a common understanding of how to interpret and translate elements in the graph, common ontologies and taxonomies must be used. These are also needed for the interpretation of skills and sub-skills as there is e.g. inheritance in ontologies which must be known by the Knowledge Agent to resolve relations.

BUILDING BLOCK COMPONENTS​

USE-CASE-SPECIFIC COMPONENTS​

SubsystemDescription
RuL Consuming AppThis component is the app that is hosted at the consumer and provides the end user interface.
Usage DataA data source at the data provider that provides usage data that are required for RuL prognosis services.
It can be accessed by the Knowledge Agent via data bindings.
RuL ServiceA calculation service at the Supplier. It accepts load spectra as parameters, and calculates the Remaining useful Life result values and returns them.

KNOWLEDGE AGENT COMPONENTS AND CATENA-X CORE SERVICES​

For non-use-case-specific components, refer to the general Architecture section in the general adoption view.