Skip to content

Commit e5fb49a

Browse files
committed
fmi simulation docs added
1 parent 4fdfee3 commit e5fb49a

File tree

9 files changed

+690
-7
lines changed

9 files changed

+690
-7
lines changed

docs/docs/fmi/API.md

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
sidebar_position: 3
3+
---
4+
5+
# API Documentation
6+
7+
Welcome to the Example API documentation. This API allows developers to interact with our services easily and efficiently.
8+
9+
## Table of Contents
10+
11+
- [Introduction](#introduction)
12+
- [Endpoints](#endpoints)
13+
- [GET /users](#get-users)
14+
- [POST /users](#post-users)
15+
16+
## Introduction
17+
18+
This API provides access to FMU data and allows for the creation and management of simulation schemas and simulations. It is based on REST and returns responses in JSON format.
19+
20+
## Endpoints
21+
22+
### FMU endpoints
23+
24+
| Method | Endpoint | Description |
25+
|--------|------------------------------|---------------------------------------------|
26+
| GET | /fmi/fmus/{context} | Retrieve a list of FMUs |
27+
| POST | /fmi/fmus/{context} | Upload a new FMU |
28+
| GET | /fmi/fmus/{context}/{fmuName}| Retrieve FMU information within a context |
29+
| DELETE | /fmi/fmus/{context}/{fmuName}| Delete a FMU within a context |
30+
31+
32+
---
33+
34+
### Schema endpoints
35+
36+
| Method | Endpoint | Description |
37+
|--------|-----------------------------------|---------------------------------------------|
38+
| GET | /fmi/schemas/{context} | Retrieve a list of schemas |
39+
| POST | /fmi/schemas/{context} | Upload a new schema |
40+
| GET | /fmi/schemas/{context}/{schema_id}| Retrieve a schema within a context |
41+
| DELETE | /fmi/schemas/{context}/{schema_id}| Delete a schema within a context |
42+
43+
---
44+
45+
### Simulation endpoints
46+
47+
| Method | Endpoint | Description |
48+
|--------|--------------------------------------------------|-------------------------------------------|
49+
| GET | /fmi/simulations/{context} | Retrieve a list of running simulations |
50+
| POST | /fmi/simulations/{context} | Deploy simulation |
51+
| GET | /fmi/simulations/{context}/{simulation_id} | Retrieve simulation info within a context |
52+
| DELETE | /fmi/simulations/{context}/{simulation_id} | Delete a simulation within a context |
53+
| POST | /fmi/simulations/{context}/{simulation_id}/resume| Resume a specific simulation |
54+
| POST | /fmi/simulations/{context}/{simulation_id}/pause | Stops a specific simulation |

docs/docs/fmi/_category_.json

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
{
2+
"label": "FMI Simulation",
3+
"position": 5,
4+
"link": {
5+
"type": "generated-index",
6+
"description": "OpenTwins supports the Functional Mock-up Interface (FMI) standard for simulation."
7+
}
8+
}

docs/docs/fmi/concepts.mdx

Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
---
2+
sidebar_position: 2
3+
---
4+
5+
import useBaseUrl from '@docusaurus/useBaseUrl';
6+
import ThemedImage from '@theme/ThemedImage';
7+
8+
9+
# FMI Simulation concepts
10+
11+
:::warning
12+
The FMI simulation service is currently being tested.
13+
:::
14+
15+
## Simulation schema
16+
The schema is used to create simulation blueprints to store and create several simulation instances.
17+
18+
The schema can be create for a single FMU or several FMUs. The schema for a single FMU is:
19+
20+
```json
21+
{
22+
"id":"schema1",
23+
"name":"Schema 1",
24+
"description":"Sample schema",
25+
"relatedTwins":[
26+
"Twin1"
27+
],
28+
"fmus":[
29+
{
30+
"id": "Controller",
31+
"inputs": [
32+
{"id": "u_s"},
33+
{"id": "u_m"}
34+
],
35+
"outputs": [
36+
{"id": "y"}
37+
]
38+
}
39+
]
40+
}
41+
```
42+
43+
<details>
44+
<summary><b>Schema for several FMUs</b></summary>
45+
46+
The following schema is designed to be used with multiple FMUs:
47+
48+
```tsx
49+
{
50+
"id":"schema1",
51+
"name":"Schema 1",
52+
"description":"Sample schema",
53+
"relatedTwins":[
54+
"Twin1"
55+
],
56+
"fmus":[
57+
{
58+
"id": "Controller",
59+
"inputs": [
60+
{"id": "u_s"},
61+
{"id": "u_m"}
62+
],
63+
"outputs": [
64+
{"id": "y"}
65+
]
66+
},
67+
{
68+
"id": "Drivetrain",
69+
"inputs": [
70+
{"id": "tau"}
71+
],
72+
"outputs": [
73+
{"id": "w"}
74+
]
75+
}
76+
],
77+
"schema":[
78+
{
79+
"from": {"var": "w_ref"},
80+
"to": {"id": "controller", "var": "u_s"}
81+
},
82+
{
83+
"from": {"id": "drivetrain", "var": "w"},
84+
"to": {"id": "controller", "var": "u_m"}
85+
},
86+
{
87+
"from": {"id": "controller", "var": "y"},
88+
"to": {"id": "drivetrain", "var": "tau"}
89+
},
90+
{
91+
"from": {"id": "drivetrain", "var": "w"},
92+
"to": {"var": "w"}
93+
}
94+
]
95+
}
96+
```
97+
98+
99+
This will work properly, although hovering over`ApparentGreetProps`may be a little intimidating. You can reduce this boilerplate with the`ComponentProps` utility detailed below.
100+
101+
</details>
102+
103+
104+
## Simulation running schema
105+
106+
Once you have a schema stored in the system, you can create a simulation instance using that schema:
107+
108+
```json
109+
{
110+
"id":"Simulation1",
111+
"name":"Simulation1",
112+
"schemaId": "schema1",
113+
"targetConnection":{
114+
"BROKER_TYPE" : "mqtt",
115+
"BROKER_IP" : "",
116+
"BROKER_PORT" : "",
117+
"BROKER_TOPIC" : "",
118+
"BROKER_USERNAME" : "",
119+
"BROKER_PASSWORD" : ""
120+
},
121+
"configuration":{
122+
"SIMULATION_START_TIME":1,
123+
"SIMULATION_END_TIME":7,
124+
"SIMULATION_STEP_SIZE":1,
125+
"SIMULATION_DELAY_WARNING": 1,
126+
"SIMULATION_LAST_VALUE": true,
127+
"SIMULATION_TYPESCHEDULE": "one-time"
128+
},
129+
"inputs":[],
130+
"outputs": []
131+
}
132+
133+
```
134+
135+
This schema is not different for one or several FMUs execution. It only contains information about execution.

docs/docs/fmi/installation.md

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
1+
---
2+
sidebar_position: 1
3+
---
4+
5+
# Installation Guide
6+
7+
:::warning
8+
9+
The FMI simulation service is currently being tested, so please be patient, as soon as it is properly tested, the public image will be available on Docker Hub.
10+
11+
:::
12+
13+
14+
This guide explains how to install the component using two methods:
15+
1. **Helm** (Work in Progress)
16+
2. **Manual Installation** using Kubernetes manifests (Deployment and Service)
17+
18+
## Prerequisites
19+
This guide asumes that you have OpenTwins already installed.
20+
21+
Before you begin, ensure you have the following:
22+
- Access to a Kubernetes cluster
23+
- `kubectl` installed and configured
24+
- [Helm](https://helm.sh/docs/intro/install/) (for Helm installation)
25+
26+
---
27+
28+
## Method 1: Helm Installation (WIP)
29+
:::warning
30+
31+
This method is currently a Work in Progress (WIP) and may not be fully functional yet. We recomend using manual installation.
32+
33+
:::
34+
35+
1. **Add the Helm repository** (once available):
36+
```bash
37+
helm repo add ertis https://ertis-research.github.io/Helm-charts/
38+
```
39+
40+
2. **Update Helm repositories**:
41+
```bash
42+
helm repo update
43+
```
44+
45+
3. **Install the component**:
46+
```bash
47+
helm install <release-name> <chart-name> --namespace <namespace>
48+
```
49+
50+
For additional configuration options, refer to the [Helm documentation](https://helm.sh/docs/).
51+
52+
---
53+
54+
## Method 2: Manual Installation
55+
You can manually deploy the component by creating a Kubernetes Deployment resource and a Service.
56+
57+
58+
### Step 1: Deploy the Kubernetes Deployment
59+
Create a YAML file for the Deployment (e.g., `deployment.yaml`):
60+
61+
```yaml
62+
63+
apiVersion: apps/v1
64+
kind: Deployment
65+
metadata:
66+
labels:
67+
name: opentwins-fmi-api
68+
name: opentwins-fmi-api
69+
spec:
70+
replicas: 1
71+
selector:
72+
matchLabels:
73+
name: pod-opentwins-fmi-api
74+
template:
75+
metadata:
76+
labels:
77+
name: pod-opentwins-fmi-api
78+
name: opentwins-fmi-api
79+
spec:
80+
serviceAccountName: ot-agents
81+
automountServiceAccountToken: true
82+
containers:
83+
- image: ertis/opentwins-fmi-simulator-api-v2:latest
84+
name: opentwins-fmi-api
85+
env:
86+
- name: KUBE_NAMESPACE
87+
value:
88+
- name: INSIDE_CLUSTER
89+
value:
90+
- name: INFLUXDB_HOST
91+
value:
92+
- name: INFLUXDB_TOKEN
93+
value:
94+
- name: INFLUXDB_DB
95+
value:
96+
- name: MINIO_TOKEN
97+
value:
98+
- name: MINIO_URL
99+
value:
100+
- name: MINIO_A_KEY
101+
value:
102+
- name: MINIO_S_KEY
103+
value:
104+
- name: POSTGRE_HOST
105+
value:
106+
- name: POSTGRE_PORT
107+
value:
108+
- name: POSTGRE_DB
109+
value:
110+
- name: POSTGRE_USER
111+
value:
112+
- name: POSTGRE_PASSWORD
113+
value:
114+
- name: BROKER_TYPE
115+
value:
116+
- name: BROKER_IP
117+
value:
118+
- name: BROKER_PORT
119+
value:
120+
- name: BROKER_TOPIC
121+
value:
122+
- name: BROKER_USERNAME
123+
value:
124+
- name: BROKER_PASSWORD
125+
value:
126+
ports:
127+
- containerPort: 8001
128+
imagePullPolicy: Always
129+
```
130+
131+
Apply the Deployment using the following command:
132+
133+
```bash
134+
kubectl apply -f deployment.yaml -n <namespace>
135+
```
136+
137+
### Step 2: Create a Kubernetes Service
138+
Next, create a YAML file for the Service (e.g., `service.yaml`):
139+
140+
```yaml
141+
apiVersion: v1
142+
kind: Service
143+
metadata:
144+
name: opentwins-fmi-api
145+
spec:
146+
selector:
147+
name: pod-opentwins-fmi-api
148+
type: NodePort
149+
ports:
150+
- protocol: "TCP"
151+
port: 8000
152+
nodePort: <PORT>
153+
targetPort: 8000
154+
155+
```
156+
157+
Apply the Service configuration using the following command:
158+
159+
```bash
160+
kubectl apply -f service.yaml -n <namespace>
161+
```
162+
163+
### Step 3: Verify the installation
164+
165+
After deploying both the deployment and the service, veryfy that everything is running correctly:
166+
167+
```bash
168+
kubectl get deployments -n <namespace>
169+
kubectl get services -n <namespace>
170+
```
171+
172+
You should see your Deployment and Service listed, and the component should be ready for use.

docs/docs/installation/requirements.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,11 @@ sidebar_position: 1
77
This page lists both software and hardware requirements for using OpenTwins.
88

99
## Hardware requirements
10-
- 2 CPU cores
11-
- 8 GB of RAM
10+
- ### For standard architecture
11+
- 2 CPU cores
12+
- 8 GB of RAM
13+
- ### For lightweight architecture
14+
- Raspberry Pi 4
1215

1316
## Software requirements
1417
- Container manager:

0 commit comments

Comments
 (0)