The aim of this work is to create a toolset to monitor and simulate industrial processes like production and processing plants, resource management for project-based teams, budgeting in complex cases, etc.

The model could be used for:

project monitoring;
project optimisation;
project automation;

Not-aim

Creating GUI is currently out of scope.

Technical process simulation is done with Controls-kt.

Project strategy management is currently out of scope.

Concepts

The project is based on several main constructs:

Resource/object graph

The current state of the system is described as a graph structure where each node is a separate entity. Each node has a type and unique ID. Some node types could also have parameters, that could not be changed after node creation.

Node can have any number of attributes (they could be added, removed and replaced). Attributes define the current node state.

Node can have external descriptor that stores meta-information about the node. Like access rights, visualization preferences, etc.

Attributes

Attributes are strongly typed containers for values. An attribute key stores information about attribute name and attribute type. Also, it could store information about default values and serialization rules.

Some attributes are relations that connect two nodes with specific directed connection. Currently, we use only one-to-one relations.

To be discussed: attributes could have their own attributes either defined in themselves, or in schema.

Work

Work is a list of events that contains rules to modify object graph. Basically it has the following events:

add node;
remove node;
modify attribute (add/remove/replace);

Work also could have events that do not modify resource graph but still should be monitored. Like change of external balance.

Work events are consumed by a work graph with respect to attached processes. It is possible that the process rejects node change. It is also possible that the process adds new node changes based on the graph state.

To be discussed: In case of event rejection, part of work could still be completed based on rules and event relations. The specific rules should be further discussed.

Process

A "smart-contract" (no blockchain yet) that defines automatic changes to object graph based on work being done.

History

The log of all changes in object graph. It could be used to construct "time machine" and reverse the state of the graph to any state in the past. The history events mirror work events.

Further discussion

Time management is out of the scope for now, but it should be considered in the future. For example, there should be possibility to add delay to the process and allow it to propagate in a virtual time. Timeline from simulations-kt could be used for that.