fml40-reference-implementation

Reference implementation of the forest modelling language 4.0 (fml 4.0) which is explained in a KWH 4.0 white paper (not public yet).

Features

• launching digital twins in single shot or persistent mode via fml40s.py
• extending the capabilities with user defined digital twins

Requirements

Python >= 3.6.6

Installation

Run pip install -m requirements

Usage

A digital twin can be launched in persistent mode by executing

python fml40s.py launch <path to config file>

If called with --singleshot option the digital twin receives all available messages, potentially sends some messages and shuts down afterwards.

For more options call

python fml40s.py -h

Extending with user defined classes

A new thing can be implemented by creating a python class which inherits from ManagingActor or an existing machine. In order to use the class, it has to be registered to DT_FACTORY within fml40s.py.

Config files

A valid configuration consists of exactly one json object. Mandatory fields of the json object are

• client_secret,
• thingId and
• type

MyDigitalTwin.json:

{
  "client_secret": "secret",
  "thingId": "s3i:id",
  "type": "Komatsu",
  "functionalities": [
    {
      "type": "AcceptsForwardingJobs",
      "proxy": "Forwards"
    }
}

Optionally a list named functionalities can be defined. The objects contained by this list specify the functionalities a thing has. Currently a list entry has the following structure:

{
  "type": "Harvests",
  "receiver": "s3i:3154edfa-5b04-4a28-b803-d6ec46135c19",
  "proxy": "ManageJobs"
}

In both cases type has to match the exact class name of the thing or functionality. The fields proxy and receiver are option. proxy can be used to specify a functionality that will be executed afterwards. If this functionality is going to send messages, the id of the receiving thing has to be declared in receiver.

Structure

Configs

This folder contains example configuration files in json format for some digital twins.

Functionalities

This directory includes the implementations of the functionalities as described in the fml40 white paper.

Machines

Contains base classes for machines. The base classes are implemented as Managing Actors since these actors always manage different functionalities, which are Managed Actors.

Managed Actor

A managed actor is an actor with reference to the pykka implementation. To instantiate a managed actor, an associated Managing Actor is needed. The managed actor registers at this managing actor.

Managing Actor

A managing actor has a dict proxyFunctionalities that lists all actors/functionalities the managing actor manages. The dict assigns the names of the managed actor to their proxy reference (see also pykka proxies). Also, the managing actor stops all its managed actors listed in its dict before it is stopped itself.

Tools

Implements service functions that can be used. Currently, also S³I interface functions like sending a service request are implemented here. These kind of functions should be outsourced in an interfaces directory soon.

Customer code example

Example implementation of a JohnDeere harvester, Ponsse harvester and Komatsu forwader.