Metamodel concepts of IEC 62264 are being converted to a set of PDDL type specifications and predicates. Relevant elements are those that appear within a given IEC 62264 model. Unused elements are not translated in order to reduce file size and increase performance and readability.
Where the last predicate `(MaterialLotClassed ?L - MaterialLot ?C - MaterialClass)` is the composition of `defined by` and `grouped by` in the material information model.
## Model Concepts
IEC 62264 instance data is converted into PDDL information using the rules laid out in the following clauses. Note, that we are using class diagram visual syntax instead of object diagram syntax due to limitations in the used Markdown rendering engine.
### * Class and Material Definition
`* Class` and `Material Definition` instances are converted to constants
From
```mermaid
classDiagram
class MaintenanceEngineer
<<PersonnelClass>> MaintenanceEngineer
class PositioningUnit
<<EquipmentClass>> PositioningUnit
class Chassis
<<MaterialClass>> Chassis
class ChassisBlack
<<MaterialDefinition>> ChassisBlack
```
to
```pddl
(:constants
PC_MaintenanceEngineer - PersonnelClass
EC_PositioningUnit - EquipmentClass
MC_Chassis - MaterialClass
MD_Chassis-Black - MaterialDefinition
)
```
### * Class Property and Material Definition Property
Boolean `* Class Property` and `Material Definition Property` instances are converted to predicates and actions. Non-boolean properties are not supported in the current state of implementation. The actions are only generated, if the property is not marked as of kind `implicit`, in which case the corresponding predicate is only triggered by other actions' effects.
From
```mermaid
classDiagram
class PositioningUnit
<<EquipmentClass>> PositioningUnit
class Locked
<<EquipmentClassProperty>> Locked
PositioningUnit *-- Locked : has property
```
to
```pddl
(:predicates
(PositioningUnitLocked ?E - Equipment)
)
(:action LockPositioningUnit
:parameters (?E - Equipment)
:precondition
(and
(EquipmentClassed ?E EC_PositioningUnit)
(not (PositioningUnitLocked ?E))
)
:effect
(and
(increase (total-cost) 1)
(PositioningUnitLocked ?E)
)
)
(:action UnlockPositioningUnit
:parameters (?E - Equipment)
:precondition
(and
(EquipmentClassed ?E EC_PositioningUnit)
(PositioningUnitLocked ?E)
)
:effect
(and
(increase (total-cost) 1)
(not (PositioningUnitLocked ?E))
)
)
```
Please, note that we have applied hard-coded "pretty-printing" to some of the `* Class Property` instances. In the above case `PositioningUnit`'s `locked` is translated into the terms `LockPositioningUnit` and `UnlockPositioningUnit`. The default translation for this instance would be `PositioningUnitLockedTrue``PositioningUnitLockedFalse`. Action cost for setting a property are considered to be 1.
### Resource Network Connection Type
`Resource Network Connection Type` instances are converted to predicates.
Please, note that we have applied hard-coded "pretty-printing" to some of the `ResourceNetworkConnectionType` instances. In the above case `EquipmentReachTo` is translated into the term `ReachesTo`.
### Process Segment
`Process Segment` instances are converted to actions, with their `* Segment Specification` instances becoming their parameters and being used in certain pre and post condition statements. In the example below, we are not listing all elements specified in the IEC 62264 input model, as this would increase complexity a lot. Instead, we are listing the main elements of the input model, but we are listing the complete result for the PDDL domain description.
Please, note that we are adding a few pre- and post conditions hard-coded in the transformation process, based on our knowledge of the underlying production system, e.g., utilization of the `EquipmentLocation` and `TransportationNodeConnection` predicates.
Further, the action cost are encoded as a function `shuttle-time` that is filled with values in the PDDL problem description.
# PDDL Problem Definitions
## Person, Equipment, and Material Lot
Instances of `Person`, `Equipment`, and `Material Lot` are converted to objects. Their relations to `* Class` or `Material Definition` instances are materialized as initialization statements.
From
```mermaid
classDiagram
class MaintenanceEngineer1
<<Person>> MaintenanceEngineer1
class MaintenanceEngineer
<<EquipmentClass>> MaintenanceEngineer
class Shuttle1
<<Equipment>> Shuttle1
class Shuttle
<<EquipmentClass>> Shuttle
class ChassisBlack1
<<MaterialLot>> ChassisBlack1
class ChassisBlack
<<MaterialDefinition>> ChassisBlack
class Chassis
<<MaterialClass>> Chassis
MaintenanceEngineer1 --> MaintenanceEngineer : defined by
`Resource Network Connection` instances of type `Transport-System-Track-Connection` and `Transport-System-Positioning-Unit-Connection` are converted in a very specific way. The former raw connections represent the physical connections of all track curves, lines, and switches. The latter represent the physical location where a positioning unit has been attached to a track. This information is read in, and a directed graph structure is generated. Here, we already show a simplified graph where only topologically important elements are kept (curves and straight lines without positioning units attached are removed). Elements starting with a `J` are `Joins`, `D` depicts `Divides`, and `A` represents a special item, an `Arena` (two inputs, two outputs). Stadium-shaped nodes depict positioning units.
In order to reduce computational complexity for the PDDL solver, an even more simplified topology is computed that only contains the positioning units and leaves out all intermediate elements. The edge weight of the graph corresponds to the physical track length between the positioning units and is converted into seconds based on an assumed average speed of 0.56 m/s.
For each "positioning unit connection" two init statements are created: one that states that these two positioning units are connected with each other (`TransportationNodeConnection`), and another one setting the function value for the function `shuttle-time`, representing the estimated traveling time in seconds between these two positioning units. The resulting PDDL init statements are listed below:
Information about what material can be assembled from what other material is captured from the `assembly` relation in the `MaterialClass` and `MaterialDefinition` instances.
From
```mermaid
classDiagram
class OpenTopBlackYellowBlue
<<MaterialDefinition>> OpenTopBlackYellowBlue
class ChassisBlack
<<MaterialDefinition>> ChassisBlack
class CabinYellow
<<MaterialDefinition>> CabinYellow
class BodyOpenTopBlue
<<MaterialDefinition>> BodyOpenTopBlue
OpenTopBlackYellowBlue --> BodyOpenTopBlue : assembled from
OpenTopBlackYellowBlue --> CabinYellow : assembled from
OpenTopBlackYellowBlue --> ChassisBlack : assembled from
Information about the current assembly state are expressed through the assembly relation of the `MaterialLot` relation. This is not only used to express the current state, but also for the formulation of goal statements, es depicted below. The `from` IEC 62264 model is extracted from the [goal description model](../iec62264/CIIRC-Testbed-TASE-Goal-1.iec62264).
From
```mermaid
classDiagram
class OpenTopBlackYellowBlue1
<<MaterialLot>> OpenTopBlackYellowBlue1
class ChassisBlack1
<<MaterialLot>> ChassisBlack1
class CabinYellow1
<<MaterialLot>> CabinYellow1
class BodyOpenTopBlue1
<<MaterialLot>> BodyOpenTopBlue1
OpenTopBlackYellowBlue1 --> BodyOpenTopBlue1 : assembled from
OpenTopBlackYellowBlue1 --> CabinYellow1 : assembled from
OpenTopBlackYellowBlue1 --> ChassisBlack1 : assembled from
