David Alessandro Bauer

dblp:257/6044 · DBLP profile ↗
← Back
4ranked-venue papers
4as first author
3since 2021 · last 2025
0009-0008-6247-7548ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 4 · 4 first-author · 3 since 2021
YearPublicationVenuePosition
2025 Multi-Runtime Actor Model Implementation and Benchmarks
abstract
This paper describes and evaluates three approaches to actor model runtime implementations. The classic approach is to use one queue per actor. A thread-bound approach where the queue is shared through the actors designated to one thread, and virtual threads from the JDK 21, used for I/O operations, and treated here as actors in the third-developed runtime. Furthermore, minimalistic implementations are compared to the implemented ones in Actor4j. Intra-communication still wins when actors can be grouped on the same thread. Suppose coordination (inter-communication) between a vast number of actors is a necessity. In that case, a classic approach is the better approach, as it has more flexibility in handling these tasks, especially as it supports work-stealing.
David Alessandro Bauer, Juho Mäkiö
IECON1
2023 A Lightweight MES Using RAMI4.0 on the Example of Smart Insect Farms
abstract
Reference Architecture Model Industry 4.0 (RAMI4.0) compliant Manufacturing Operation System (MES) implementations require high investments, which put them out of reach for small and medium-sized enterprises. This work presents a lightweight RAMI4.0-compliant MES. The underlying proposed architecture of the Cognitive Robotic System for Digitalized and Networked (Automated) Insect Farms (CoRoSect) project ensures communication and information interoperability within the shop and office floor. The repository pattern is used for sharing data by integrating secondary Asset Administration Shells (AASs) as an information hub. We propose further enhancements by implementing higher-level AASs for edge or public cloud use. The path taken for reaching this goal can be especially interesting for Small and Medium Enterprises (SMEs) because of the simplified implementation and for other researchers by improving this procedure in a more complete solution. First, pilots show the practicality of the provided solution.
David Alessandro Bauer, Juho Mäkiö
IECON1
2022 Actor-Oriented Scalable Domain-Specific Cluster Architecture for Cloud-Applications
abstract
Nowadays, applications in the cloud are based on a microservice architecture. Depending on the problem to be solved, they tend to grow complex, and the maintenance is more complicated. For this, a scalable domain-specific (application-related) cluster architecture is conceptualized, which should fulfill the requirements of flexibility, scalability and elasticity, cost-effectiveness, and reliability. Each instance within the cluster covers an application domain. It is possible to upload service subdomains dynamically to an application domain at runtime. A subdomain consists of a group of actors (also called a pod). The development of a subdomain can be assigned to a team. A service subdomain can be scaled individually through replication or sharding (within the instance or the cluster). The proposed solution is expected to achieve a better result than a microservice or FaaS architecture. A single instance prototype was already developed, and a demo application was created.
David Alessandro Bauer, Juho Mäkiö
IECON1
2019 Hybrid Cloud - Architecture for Administration Shells with RAMI4.0 Using Actor4j
abstract
In this paper, the actor-oriented Java framework Actor4j is used to implement administration shells in a RAMI4.0 context to enable the implementation of hybrid cloud solutions. A novel architecture is conceptualized around the usage of the Actor Model, especially in the area of edge and cloud computing. The administration shell can be either implemented by an asset that is OPC-UA ready or be mapped to a gateway in the device (service) cloud. The administration shell implemented with the Actor Model (predominantly for the public and private cloud) consists of four modules: the components module (describing the corresponding system), the publish-subscribe module, the additional logic module (conditions, alarms), and the interaction module (behavior). The main idea is to reuse an OPC-UA compliant implementation for the internal actor logic. At the device cloud level, IT/OT entities can be composed together in a domain specific point of view. This is implemented over three abstractions levels (data acquisition, data analytics and control & monitoring). The proposed Actor Model fits very well for the implementation of large scale administrations shells.
David Alessandro Bauer, Juho Mäkiö
INDIN1