Skip to content

Commit f385078

Browse files
authored
Merge pull request #1 from Electrostat-Lab/joss-paper
Add Delta-Engine paper with abstract and methodologies
2 parents dd7b471 + 6cae7fb commit f385078

3 files changed

Lines changed: 757 additions & 0 deletions

File tree

paper/architecture.dot

Lines changed: 288 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,288 @@
1+
digraph newtonian_rti {
2+
subgraph cluster_engine {
3+
fontname="Helvetica"
4+
fontcolor="#CECBF6"
5+
style="rounded,filled"
6+
fillcolor="#8F8F8F"
7+
color="#8F8F8F"
8+
fontcolor="#FFFFFF"
9+
fontsize=12
10+
penwidth=1.2
11+
margin=16
12+
13+
graph [
14+
rankdir=TB
15+
fontname="Helvetica"
16+
fontsize=20
17+
bgcolor="transparent"
18+
pad=0.5
19+
nodesep=0.3
20+
ranksep=0.25
21+
label="Δ-Engine Architecture (GPLv3)"
22+
labelloc=t
23+
labeljust=c
24+
splines=false
25+
compound=true
26+
]
27+
node [
28+
fontname="Helvetica"
29+
shape=box
30+
style="rounded,filled"
31+
penwidth=0.8
32+
width=5.5
33+
margin="0.25,0.18"
34+
]
35+
edge [
36+
fontname="Helvetica"
37+
fontsize=10
38+
arrowhead=vee
39+
arrowsize=0.7
40+
penwidth=0.8
41+
color="#9C9A92"
42+
]
43+
44+
45+
// ── Newtonian RII — Amber ─────────────────────────────────────────────
46+
subgraph cluster_rti {
47+
label="[0] Atomic Newtonian RTI — Physics Spaces\nTop-level simulation environment and scene API"
48+
fontname="Helvetica"
49+
fontcolor="#CECBF6"
50+
style="rounded,filled"
51+
fillcolor="#633806"
52+
color="#EF9F27"
53+
fontcolor="#FFFFFF"
54+
fontsize=12
55+
penwidth=1.2
56+
margin=16
57+
58+
node [
59+
fontname="Helvetica"
60+
fontsize=11
61+
shape=box
62+
style="rounded,filled"
63+
fillcolor="#733806"
64+
color="#733806"
65+
fontcolor="#FFFFFF"
66+
penwidth=0.8
67+
width=1.0
68+
margin="0.18,0.14"
69+
]
70+
71+
_molecular [ label="Molecular Component" ]
72+
_inertia [ label="Inertial Ref. Frames Component" ]
73+
_forceacc [ label="Accelerating Component" ]
74+
_interaction [ label="Interaction Component" ]
75+
76+
{ rank=same _molecular _inertia _forceacc _interaction }
77+
78+
// invisible edges to enforce left-to-right ordering
79+
_molecular -> _inertia -> _forceacc -> _interaction [ style=invis ]
80+
}
81+
82+
// ── Physics Mechanics cluster ─────────────────────────────────────────
83+
subgraph cluster_physics {
84+
label="[1] Physics Mechanics Modules"
85+
fontname="Helvetica"
86+
fontsize=12
87+
fontcolor="#FFFFFF"
88+
style="rounded,filled"
89+
fillcolor="#3C3489"
90+
color="#AFA9EC"
91+
penwidth=1.2
92+
margin=16
93+
94+
node [
95+
fontname="Helvetica"
96+
fontsize=11
97+
shape=box
98+
style="rounded,filled"
99+
fillcolor="#26215C"
100+
color="#26215C"
101+
fontcolor="#FFFFFF"
102+
penwidth=0.8
103+
width=1.0
104+
margin="0.18,0.14"
105+
]
106+
107+
PM_mech [ label="Solid Mechanics" ]
108+
PM_fluid [ label="Fluid Dynamics" ]
109+
PM_therm [ label="Thermodynamics" ]
110+
PM_em [ label="Electromagnetism" ]
111+
112+
{ rank=same PM_mech PM_fluid PM_therm PM_em }
113+
114+
// invisible edges to enforce left-to-right ordering
115+
PM_mech -> PM_fluid -> PM_therm -> PM_em [ style=invis ]
116+
}
117+
118+
subgraph cluster_sdk {
119+
label="The Electrostatic-Sandbox SDK (GPLv3)"
120+
fontname="Helvetica"
121+
fontcolor="#CECBF6"
122+
style="rounded,filled"
123+
fillcolor="#000000"
124+
color="#000000"
125+
fontcolor="#FFFFFF"
126+
fontsize=12
127+
penwidth=1.2
128+
margin=16
129+
// ── Mathematical Libraries — Blue ─────────────────────────────────────
130+
subgraph cluster_mathlibs {
131+
label="[2] Mathematical Libraries"
132+
fontname="Helvetica"
133+
fontsize=12
134+
fontcolor="#CECBF6"
135+
style="rounded,filled"
136+
fillcolor="#0C447C"
137+
color="#85B7EB"
138+
fontcolor="#FFFFFF"
139+
penwidth=1.2
140+
margin=16
141+
142+
node [
143+
fontname="Helvetica"
144+
fontsize=11
145+
shape=box
146+
style="rounded,filled"
147+
fillcolor="#26215C"
148+
color="#26215C"
149+
fontcolor="#FFFFFF"
150+
penwidth=0.8
151+
width=1.0
152+
margin="0.18,0.14"
153+
]
154+
155+
_vectors [ label="Vector Math" ]
156+
_calculus [ label="Calculus" ]
157+
_matrix [ label="Matrix Algebra" ]
158+
159+
{ rank=same _vectors _calculus _matrix }
160+
161+
// invisible edges to enforce left-to-right ordering
162+
_vectors -> _calculus -> _matrix [ style=invis ]
163+
}
164+
165+
// ── IO VM — Teal ──────────────────────────────────────────────────────
166+
167+
subgraph cluster_vmio {
168+
label="[3] IO VM (VMIO)\nVirtualised IO interface — platform-agnostic dispatch"
169+
fontname="Helvetica"
170+
fontsize=12
171+
fontcolor="#CECBF6"
172+
style="rounded,filled"
173+
fillcolor="#085041"
174+
color="#5DCAA5"
175+
fontcolor="#FFFFFF"
176+
penwidth=1.2
177+
margin=16
178+
179+
node [
180+
fontname="Helvetica"
181+
fontsize=11
182+
shape=box
183+
style="rounded,filled"
184+
fillcolor="#115022"
185+
color="#115022"
186+
fontcolor="#FFFFFF"
187+
penwidth=0.8
188+
width=1.0
189+
margin="0.18,0.14"
190+
]
191+
192+
_analog [ label="Analog Driver" ]
193+
_digital [ label="Digital Driver" ]
194+
_comm [ label="Comm Driver" ]
195+
_memory [ label="Memory Driver" ]
196+
197+
{ rank=same _analog _digital _comm _memory }
198+
199+
// invisible edges to enforce left-to-right ordering
200+
_analog -> _digital -> _comm -> _memory [ style=invis ]
201+
}
202+
203+
// ── IO Infrastructure — Coral ─────────────────────────────────────────
204+
205+
subgraph cluster_io {
206+
label="[4] IO Infrastructure"
207+
fontname="Helvetica"
208+
fontsize=12
209+
fontcolor="#CECBF6"
210+
style="rounded,filled"
211+
fillcolor="#712B13"
212+
color="#F0997B"
213+
fontcolor="#FFFFFF"
214+
penwidth=1.2
215+
margin=16
216+
217+
node [
218+
fontname="Helvetica"
219+
fontsize=11
220+
shape=box
221+
style="rounded,filled"
222+
fillcolor="#912B13"
223+
color="#912B13"
224+
fontcolor="#FFFFFF"
225+
penwidth=0.8
226+
width=1.0
227+
margin="0.18,0.14"
228+
]
229+
230+
_gpio [ label="GPIO" ]
231+
_spi [ label="SPI" ]
232+
_i2c [ label="I2C" ]
233+
_pwm [ label="PWM" ]
234+
_adc [ label="ADC" ]
235+
_eeprom [ label="EEPROM" ]
236+
237+
{ rank=same _gpio _spi _i2c _pwm _adc _eeprom }
238+
239+
// invisible edges to enforce left-to-right ordering
240+
_gpio -> _spi -> _i2c -> _pwm -> _adc -> _eeprom [ style=invis ]
241+
}
242+
}
243+
244+
// ── Platform targets — Gray ───────────────────────────────────────────
245+
subgraph cluster_toolchain {
246+
label="[5] Platform-dependent Toolchain"
247+
fontname="Helvetica"
248+
fontsize=12
249+
fontcolor="#CECBF6"
250+
style="rounded,filled"
251+
fillcolor="#444441"
252+
color="#B4B2A9"
253+
fontcolor="#FFFFFF"
254+
penwidth=1.2
255+
margin=16
256+
257+
node [
258+
fontname="Helvetica"
259+
fontsize=11
260+
shape=box
261+
style="rounded,filled"
262+
fillcolor="#545451"
263+
color="#B4B2A9"
264+
fontcolor="#FFFFFF"
265+
penwidth=0.8
266+
width=1.0
267+
margin="0.18,0.14"
268+
]
269+
270+
_avr [ label="AVR" ]
271+
_arm [ label="ARM" ]
272+
_x86 [ label="x86" ]
273+
_android [ label="Android" ]
274+
275+
{ rank=same _avr _arm _x86 _android }
276+
277+
// invisible edges to enforce left-to-right ordering
278+
_avr -> _arm -> _x86 -> _android [ style=invis ]
279+
}
280+
281+
// ── Spine edges ───────────────────────────────────────────────────────
282+
_interaction -> PM_em [style=invis] [ lhead=cluster_physics ]
283+
PM_em -> _matrix [style=invis] [ ltail=cluster_physics ]
284+
_matrix -> _memory [style=invis]
285+
_memory -> _eeprom [style=invis]
286+
_eeprom -> _android [style=invis]
287+
}
288+
}

paper/paper.md

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
# Delta-Engine
2+
3+
## Abstract
4+
Scientific abstractions are one of the very useful techniques to implement software to control embedded microcontrollers for heavy machinery operations. In this paper, we introduce a physics engine that provides a new software paradigm for IO control for embedded systems and robotics based on a mathematical-physical abstraction.
5+
6+
## Keywords
7+
Embedded Systems - Embedded IO - C Programming Framework - Calculus-based Physics - Multivariate Calculus - Software programming paradigms - System Entity Structure/Model Base (SES/MB) - Hardware Abstraction Layer (HAL) - Entity Component System (ECS) - Automata Theory
8+
9+
## Knowledge Gaps (Statement of Need)
10+
There are a couple of theoretical and practical knowledge gaps that this software is going to address including, but not limited to:
11+
- [ ] Precisional IO Embedded Control of heavy machines and robotics using Scientific Abstractions (e.g., Mathematical/Physical and Chemical Abstractions).
12+
- [ ] Seamless hardware implementation of several physics simulation systems.
13+
- [ ] Single abstraction for software and hardware systems.
14+
15+
## Introduction
16+
Delta-Engine is a physics engine that provides a new software architectural paradigm for precisional IO switch and control over embedded systems and robotics without much knowledge in embedded systems, managing states and software engineering paradigms or if they fail to design the system (e.g., Object-oriented programming). It introduces the field of computational physics to the embedded world through providing a virtual machine and a runtime infrastructure based on the Newtonian physics spaces and supporting infrastructure IO libraries for several supported platforms.
17+
18+
## Methodologies
19+
- Virtualization of physics objects and IO emulation using mathematical and physical abstractions.
20+
- Newtonian physics spaces as Runtime Infrastructure (RTI).
21+
- The Abstract architectural design methodologies involve using the **Hardware-Abstraction Layer (HAL)** to model the structure of the engine in a hierarchial form and the **System-Entity-Structure/Model-Base (SES/MB) Framework** to model the structure of the engine in a more detailed form and model the relation among the subsystems and the components of the engine.
22+
- The Detailed-design methodologies involve using **Entity-Component-System (ECS)** to implement the structure of the physics engine together with the **Automata Theory**; such that, each component of the physics architecture could be represented by a system of component objects, and the system part of the ECS encapsulates state-machines; either deterministic or non-deterministic; with cyclic or non-cyclic runtime.
23+
- Therefore, the theoretical methodology of the detailed-design is the **Entity-Component-Automata (ECA)**, a formal forge of the ECS and the Automata Theory.
24+
- Implementation of several physics spaces modules (e.g., Kinematics Module - Fluid Mechanics Module); as systems of the ECA.
25+
- Building preset physics components and automata that encapsulate the mathematical/physical abstraction.
26+
- Formal linkage among the automata involved and the hardware drivers layer via callback functions $$\zeta$$; dispatched with each state transition via the transition functions $$\delta$$.
27+
28+
## High-level Architecture
29+
<img width="773" height="904" alt="architecture" src="https://github.com/user-attachments/assets/d5700f97-d21c-42fb-9279-818225b125d4" />
30+
31+
<img width="1662" height="1301" alt="ses-mb" src="https://github.com/user-attachments/assets/51447f44-0fc4-4b15-9e33-3a40257c5764" />
32+
33+
Two architectural models are being proposed here; a **hierarchial model** representing a hardware abstraction layer using a mathematical/physical abstraction, and a **System-Entity-Structure/Model-Base (SES/MB) model** to model the same system components into several subsytems; those subsystems display some components that may be formally linked with components from other subsystems (e.g., the formal linkage among Math Libraries, Mechanics Libraries, and the VMIO Libraries that enable a chained dispatch from Physics to IO).
34+
35+
### Subsystems:
36+
* Atomic Newtonian RTI: a subsystem that groups the runtime infrastructure components; its instantiation reveals the base Newtonian physics of inertia, acceleration, and object interaction in space.
37+
* Molecular Component.
38+
* Inertial Ref. frame Component.
39+
* Acceleration Component.
40+
* Interaction Component.
41+
* Physics Mechanics: a specialized subsystem of the Newtonian RTI; grouping the different types of objects in the universe that experience inertia, acceleration/deceleration, and interaction with other objects.
42+
* Solid Mechanics Module.
43+
* Fluid Dynamics Module.
44+
* Thermodynamics Module.
45+
* Electromagnetism Module.
46+
* Mathematical Libraries: a subsystem housing the base continous and discrete mathematical layer of the operations involved in the Physics Subsystems (both the Atomic/Newtonian RTI and the Physics Mechanics Subsystems).
47+
* Calculus Module.
48+
* VectorMath Module.
49+
* Matrix Algebra Module.
50+
* Virtualized IO (VMIO): a subsystem involving a platform-independent layer of driver modules to operate on the lower level platform-dependent IO infrastructure based on the output data from the Mathematical/Physical layers.
51+
* Analog Driver Module.
52+
* Digital Driver Module.
53+
* Comm Driver Module.
54+
* Memory Driver Module.
55+
* IO Infrastructure: a subsystem involving a more platform specific dependent layer of the hardware IO; grouped together in a thin abstraction layer that encapsulates a procedural runtime for the hardware IO involved; links statically with **the Platform-dependent toolchain**.
56+
* GPIO Module.
57+
* PWM Module.
58+
* UART Module.
59+
* SPI Module.
60+
* I2C Module.
61+
* EEPROM Module.
62+
* Platform-dependent toolchain: a subsystem involving a platform-dependent layer of the hardware IO and the operating system operations that are encapsulated directly by the IO Infrastructure subsystem and indirectly by the Platform-agnostic VMIO subsystem.
63+
* Android Userspace Runtime.
64+
* AVR Runtime.
65+
* ARM Runtime.
66+
* x86 Userspace Runtime.
67+
68+
### Detailed Design:
69+
Detailed design could be carried out using the **Entity-Component System (ECS) Framework** to model the structure of the engine, and the **Automata Theory** to model the behavior of the engine. Both could be linked via the system part of the ECS; ECS systems can be state machines with callback functions $$\zeta$$ dispatched after each state-state transition or from the $$\delta$$ transition function; either deterministic or non-deterministic; cyclic or non-cyclic in runtime behavior.
70+
71+
> [!NOTE]
72+
> ## Example:
73+
> A physics object; a ball; has the following:
74+
> 1) A component that is attached to the **Inertial Ref. Frame System** through an entity `ID_BALL`.
75+
> 2) A component that is attached to the **Acceleration/Deceleration System** through an entity `ID_BALL`.
76+
> 3) A component that is attached to the **Molecular System** through an entity `ID_BALL`.
77+
> 4) A component that is attached to the **Interaction System** through an entity `ID_BALL`.
78+
> 5) A component that is attached to the **Mechanics System** through an entity `ID_BALL`.
79+
>
80+
> ## Remarks:
81+
> * It's not ideal to add a component of the ball object to the **Fluid Dynamics System**; therefore, both the **Solid Mechanics** and the **Fluid Dynamics** are specializations of the **Atomic/Newtonian RTI Subsystem**.
82+
> * It would be ideal to attach a component of the ball object to the **Fluid Dynamics System**, only if the ball is highly deformable and could be expressed in terms of fluid or semi-fluid properties (e.g., the ball is a "thrombus" in biomedical simulation).
83+
> * If that ball object is otherwise, a metallic object; it would be ideal to attach a component of it under the **Electromagnetism System**; as it could be electromagnetized under a magnetic field.
84+
> * A ball object could have { **a standard mechanical component**, **a deformable component**, and **a magnetizable component** } at the same time to enable the different types of simulations accordingly under their respective systems { **Solid Mechanics System**, **Fluid Dynamics System**, and **Electromagnetism System**}, respectively.
85+
> * The collection of the previous systems represent the core of the Delta-Engine; the **Atomic/Newtonian RTI Subsystem** and its specialization **Physics Mechanics**.
86+
> * Systems are operated using State-Machines; either deterministic or non-deterministic in nature; cyclic or non-cyclic.
87+
> * The methodology by which the Delta-Engine operates the hardware is via the axiomatic linkage among the layered subsystems of the software, and the pre-compiled platform-agnostic hardware drivers layer.
88+
> * This axiomatic linkage, described in the former bullet, is performed via a callback $$\zeta$$ function through the machines' transition functions $$\delta$$.
89+
90+
## References
91+
- [The Electrostatic-Sandbox SDK for distributed simulation systems](https://github.com/Electrostat-Lab/Electrostatic-Sandbox)
92+
- [SES/MB Framework by Throsten Pawletta](https://dl.acm.org/doi/10.5555/3108244.3108245)
93+
- [The Feynman Lectures Caltech University](https://www.feynmanlectures.caltech.edu/)
94+
- [Physics for Scientists and Engineers, 6th Edition](https://www.amazon.com/Physics-Scientists-Engineers-Paul-Tipler/dp/142920124X)
95+
- [Thomas' Calculus, 15th Edition](https://www.pearson.com/en-us/subject-catalog/p/thomas-calculus/P200000007103/9780137616077)

0 commit comments

Comments
 (0)