Hi Tom, Regarding the deployment model, the mapping between Malbec and Merlot is 1:N. Malbec can spawn as many Merlot instances as needed.
As for boot.db, it holds the PLC <-> EPICS mapping, so one boot.db corresponds to one variable set. A new variable set means a new boot.db. You can also spawn several Merlot instances with the same variables and expose different EPICS data for different purposes. Each instance loads the boot.db from its root directory when it starts. Malbec places it there when the Malbec project is compiled at the end of the design phase. For a cluster of Merlot instances, the proposal is to use Apache Karaf Cellar to manage it, since Merlot is essentially a Karaf distribution. About decoupling, that is already the case. Merlot is an independent entity, built on Apache Karaf: it retrieves data from the PLC and serves it to any client. Malbec was created to ease the configuration, but it is a design and engineering tool. The two are fully decoupled: at runtime Malbec only expects data in PVA format, so it can read it from Merlot or from any other source that serves it. The modules /api, /data and /core are UI-independent and don't rely on NetBeans, and I designed them to be usable as a library from any platform. Thanks for the interest. If you want to contribute, a PR is welcome. Best regards, Daniel El sáb, 26 sept 2026 a las 6:05, Tom NewChao (<[email protected]>) escribió: > > Hi Daniel, > > Thank you for the detailed explanation and the PlantUML script - the > layered diagram makes the component boundaries much clearer now. To me,this > is a typical industrial IoT pattern: a design-time IDE, gateways in > the middle, and PLCs at the bottom. > > I have two questions about the deployment model. First, is the intended > mapping between Malbec and Merlot 1:1 or 1:N? Our scenarios require > 1:N,with a single Malbec IDE managing multiple gateway instances. Second, I > understand boot.db is a configuration database. In a 1:N deployment, how > would the generated boot.db be pushed to each Merlot instance? In our own > scenario, we generate boot.db centrally in our platform (IDE) and then > synchronize it to every Merlot, rather than generating it on each instance. > I suspect this may be the only real difference between our designs. > > One thought on the architecture: would it be possible to decouple the core > modules - Design-Time Tooling, the Lifecycle Manager, Supervisory & > Control, and Merlot itself - from the NetBeans IDE, so they work as > standalone, IDE-independent libraries? They could then be consumed not only > by NetBeans, but also embedded into many industrial IoT platforms as > plugins for online device control and data acquisition. If these could > evolve into modules that any platform can reuse, that would be really great. > > For context: I would like to use these modules in my own industrial IoT > platform, which is not open source yet. And if you ever need an extra pair > of hands for PRs on this, I would be very happy to contribute. > > Best regards, > Tom > > Daniel Campos <[email protected]> 于2026年9月25日周五 08:48写道： > > > I just realized the mailing list stripped the image attachment from my > > previous email. Here is the PlantUML script for the architecture > > diagram I mentioned. You can copy and paste it into any PlantUML > > viewer to see the visual representation. > > > > @startuml > > !theme plain > > skinparam componentStyle rectangle > > skinparam linetype polyline > > skinparam nodesep 45 > > skinparam ranksep 90 > > skinparam padding 6 > > skinparam ArrowFontSize 11 > > skinparam NoteFontSize 11 > > skinparam DefaultFontSize 12 > > left to right direction > > > > title Malbec & Merlot Architecture Ecosystem > > > > package "Malbec IDE (NetBeans RCP)" { > > > > package "Design-Time Tooling" { > > component "S88 / Batch Project\n<<Project Type>>" as S88Proj > > component "Communications Project\n<<Project Type>>" as CommProj > > } > > > > package "Supervisory & Control" { > > component "Batch Module\n<<EPICS Client>>" as MalbecClient > > } > > > > component "Lifecycle Manager" as Lifecycle > > } > > > > package "Merlot (Runtime Gateway)" { > > database "boot.db\n(SQLite)" as BootDB > > component "PlcGroups &\nScan Engine" as ScanEngine > > component "EPICS / PVA Server" as PVAServer > > } > > > > package "Physical Layer" { > > component "PLC\n(Contiguous Memory / UDTs)" as PLC > > } > > > > ' --- Relaciones principales (orden importa para el ranking) --- > > S88Proj .right.> CommProj : Provides S88 Model\n(Lookup / plant.xml) > > CommProj --> BootDB : Generates > > BootDB --> ScanEngine : Configures\nmappings > > Lifecycle --> PVAServer : Spawns & Manages\nInstances > > ScanEngine -up-> PVAServer : Updates\nstate > > ScanEngine --> PLC : Bulk Read/Write\n(Apache PLC4X) > > MalbecClient .down.> PVAServer : Monitor & Command\n(EPICS gpClient) > > > > ' --- Notas ancladas AL LADO del elemento que describen --- > > note right of S88Proj > > Defines Plant Hierarchy and Process variables. > > end note > > > > note right of CommProj > > Maps S88 Areas to physical > > devices. Generates boot.db. > > end note > > > > note right of MalbecClient > > Uses gpClient to subscribe > > to variables and send commands. > > end note > > > > @enduml > > > > > > El jue, 24 sept 2026 a las 16:28, Daniel Campos > > (<[email protected]>) escribió: > > > > > > Hi Tom, > > > > > > To clarify the boundaries: Malbec is a multi-purpose IDE that manages > > different project types covering the plant configuration and supervision > > lifecycle. I’ve attached to this mail an architecture diagram illustrating > > these layers. > > > > > > Here is a breakdown of the ecosystem: > > > > > > 1. Design-Time Layer (Malbec IDE - NetBeans RCP) > > > Malbec acts as the central hub, managing independent and interoperable > > project types: > > > - S88 / Batch Project (my current PR scope): Models the plant hierarchy, > > defines process variables (Attributes, Parameters, Reports) with their > > metadata, and structures recipes. > > > - Communications Project: Links the S88 model (via NetBeans Lookup or > > plant.xml) to physical devices and generates the runtime configuration > > database (boot.db). > > > > > > 2. Deployment & Runtime Gateway (Merlot) > > > Merlot is a headless runtime engine spawned and managed by Malbec. Upon > > startup, it reads boot.db, organizes variables into scan groups, and uses > > Apache PLC4X to execute bulk scan/write cycles against PLC data blocks. It > > then exposes this live plant data via EPICS/PVA. > > > > > > 3. Supervisory & Control Layer (Malbec Runtime Client) > > > During execution, Malbec acts as an active supervisory client. It > > connects to Merlot using gpClient (EPICS/PVA) to subscribe to variables, > > monitor process state, and send execution commands, closing the loop > > without direct PLC wiring. > > > > > > Please keep in mind that this architecture represents our target design > > and remains a work in progress as the project evolves. > > > > > > I hope this overview clarifies the component boundaries. Looking forward > > to your thoughts. > > > > > > Best regards, > > > Daniel > > > > > > El mar, 22 sept 2026 a las 21:39, Tom NewChao (<[email protected]>) > > escribió: > > >> > > >> Hi Daniel, > > >> > > >> Thank you for the detailed explanation. It helps clarify how the > > Reference > > >> property and PlcGroups are intended to support efficient PLC access. > > >> > > >> However, to understand how these parts fit into the overall design, I > > think > > >> a more detailed layered architecture diagram would be very helpful. > > Ideally, > > >> it would provide a top-down view from the Malbec UI and S88 domain > > model, > > >> through persistence and configuration, to the Merlot runtime, PLC4X, and > > >> finally the PLC. > > >> > > >> It would also be useful to show the responsibilities and main > > interfaces of > > >> each layer, together with the principal data and control flows. > > >> > > >> At the moment, the individual mechanism is clearer to me, but the > > overall > > >> architectural view is still too coarse-grained to understand the > > complete > > >> system and the boundaries between its components. > > >> > > >> If you already have a preliminary architecture diagram, would you be > > able to > > >> share it? Even an initial version would provide a useful basis for > > further > > >> discussion. > > >> > > >> Best regards, > > >> Tom > > >> > > >> Daniel Campos <[email protected]> 于2026年9月22日周二 22:05写道： > > >> > > >> > Hi Tom, > > >> > > > >> > The challenge you mentioned regarding efficient bulk reading and > > variable > > >> > mapping is central to what we are addressing. > > >> > > > >> > To abstract manual variable-by-variable wiring from the user > > interface, S88 > > >> > elements in Malbec include a "Reference" property (a numerical index). > > >> > > > >> > This Reference serves as a multiplier in a formula used to calculate > > the > > >> > exact data block offset in the PLC memory. Instead of mapping every > > PLC tag > > >> > manually, the user in Malbec assigns a Reference index to an entity, > > >> > effectively pointing to its corresponding data block or UDT in the > > PLC. > > >> > > > >> > This approach assumes the PLC program adheres to a structured memory > > layout > > >> > where entities like analog inputs, valves, or outputs are grouped into > > >> > contiguous memory blocks of fixed size. By calculating the offset > > based on > > >> > Reference × BlockSize, Merlot can execute efficient bulk reads and > > writes > > >> > over entire memory blocks via Apache PLC4X, avoiding the overhead of > > >> > individual tag polling. > > >> > > > >> > Under the hood, Merlot manages this execution through PlcGroups. These > > >> > function as logical scan groups where tags are grouped by device and > > memory > > >> > contiguity. The goal is for Malbec to turn that "reference" into > > optimized, > > >> > bundled block requests. When Merlot boots up, it loads these group > > >> > configurations and executes the scan/write cycle. > > >> > > > >> > Best regards, > > >> > > > >> > Daniel > > >> > > > >> > El dom, 20 sept 2026 a las 22:35, Tom NewChao (<[email protected] > > >) > > >> > escribió: > > >> > > > >> > > Hi Daniel, > > >> > > > > >> > > Thanks for the explanation. The mapping you described is also one > > of the > > >> > > main challenges we face in our domain. > > >> > > > > >> > > We focus on CIM and EAP systems. Each piece of equipment has its own > > >> > > process parameters and recipes, and each recipe contains a > > corresponding > > >> > > set of parameter values. During > > >> > > production, we need to monitor both the actual process values > > reported by > > >> > > the PLC and the configured recipe setpoints. > > >> > > > > >> > > A key challenge is mapping PLC variables to the equipment > > >> > process-parameter > > >> > > model. Efficient bulk reading is essential as well. In our current > > >> > > implementation, we group > > >> > > parameters into contiguous PLC address ranges and read each range > > as a > > >> > > block, rather than issuing a separate request for every variable. > > >> > > > > >> > > Our current architecture is EAP → CIM → PLC. The CIM system owns the > > >> > > equipment model, the recipe-parameter mappings, and the equipment > > >> > adapter. > > >> > > It maps the model parameters to > > >> > > PLC variables and communicates directly with the PLC. The EAP > > system uses > > >> > > the CIM model and services for recipe management, equipment > > coordination, > > >> > > and process supervision. > > >> > > > > >> > > This is why I am particularly interested in where the mapping > > between a > > >> > > Malbec process variable and its PLC variable will live. Will the > > Malbec > > >> > > plant project contain the mapping > > >> > > metadata, with Merlot acting as the communication adapter, or will > > Merlot > > >> > > own both the mapping and the PLC communication? > > >> > > > > >> > > I hope this real-world use case is useful for the design. > > >> > > > > >> > > Best regards, > > >> > > Tom > > >> > > > > >> > > Daniel Campos <[email protected]> 于2026年9月20日周日 > > 11:25写道： > > >> > > > > >> > > > Hi, Tom! > > >> > > > > > >> > > > Thanks a lot, I appreciate your interest. > > >> > > > > > >> > > > Regarding the tags and their relationship to the physical model, > > the > > >> > main > > >> > > > goal of this model is to parameterize the plant and define the > > process > > >> > > > variables that will mirror those in the PLC. In Malbec, they're > > given > > >> > > > magnitudes, engineering units and other features for logging and > > >> > > auditing. > > >> > > > > > >> > > > As I mentioned at the end, communication is the scope of the batch > > >> > > module, > > >> > > > which I left as a placeholder for now. > > >> > > > > > >> > > > I'm planning to develop a recipe editor that is fed with the > > variables > > >> > > > defined in the plant project. > > >> > > > > > >> > > > Later, those recipes, which are basically just the variables with > > >> > defined > > >> > > > values and an execution order, will be downloaded to the PLC. > > Malbec > > >> > will > > >> > > > then be monitoring and controlling the process state, as well as > > >> > > generating > > >> > > > logs. > > >> > > > > > >> > > > This entire communication loop will go through Merlot as a gateway > > >> > > > > > >> > > > Best regards, Daniel. > > >> > > > > > >> > > > > > >> > > > El sáb, 19 de sept de 2026, 22:37, Tom NewChao < > > [email protected]> > > >> > > > escribió: > > >> > > > > > >> > > > > Hi Daniel, > > >> > > > > > > >> > > > > Congratulations on your first ASF contribution! > > >> > > > > > > >> > > > > I am also relatively new to the PLC4X community and am currently > > >> > > working > > >> > > > on > > >> > > > > the plc4net revival. It is encouraging to see another > > contributor > > >> > > working > > >> > > > > on industrial automation > > >> > > > > tooling. > > >> > > > > > > >> > > > > The separation between the S88 domain model, persistence > > adapters, > > >> > > > > application use cases, and the NetBeans UI looks very > > interesting. I > > >> > am > > >> > > > > also interested in how the physical > > >> > > > > model may eventually relate to PLC tags and industrial data > > sources. > > >> > > > > > > >> > > > > I just wanted to say hello and wish you success with the > > >> > contribution. > > >> > > I > > >> > > > > look forward to following its progress. > > >> > > > > > > >> > > > > Best regards, > > >> > > > > Tom > > >> > > > > > > >> > > > > Daniel Campos <[email protected]> 于2026年9月19日周六 > > >> > > 05:02写道： > > >> > > > > > > >> > > > > > Hi everyone, let me introduce myself again. I'm Daniel Campos > > >> > > (Dandrvms > > >> > > > > or > > >> > > > > > dacmz), from the CEOS Automatización team, working alongside > > Luis > > >> > > > > Rodríguez > > >> > > > > > and César García. As I mentioned before, I'm working on > > Malbec, an > > >> > > IDE > > >> > > > > for > > >> > > > > > industrial configuration built on top of the NetBeans RCP. > > >> > > > > > > > >> > > > > > Today I just made my first PR for this project in the > > feature/app > > >> > > > branch > > >> > > > > at > > >> > > > > > plc4x-extras, marking my very first contribution to the > > foundation. > > >> > > > Here > > >> > > > > is > > >> > > > > > a breakdown of the project structure: > > >> > > > > > > > >> > > > > > > > >> > > > > > - /api : Domain model and ports. S88Element is the minimal > > model > > >> > > > unit: > > >> > > > > > an S88 entity that can hold children and structured > > property > > >> > bags. > > >> > > > > > S88PlantModel is the orchestrator: the in-memory root of > > the > > >> > > element > > >> > > > > > tree, > > >> > > > > > the registry of classes/enumerations, and the event bus. > > >> > > Supporting > > >> > > > > > classes > > >> > > > > > provide S88ElementClass (reusable property templates), > > >> > > > S88Enumeration, > > >> > > > > > S88Level, DataType/EngineeringUnits/Magnitude, the > > >> > > > > > S88ChangeEvent/S88ChangeListener observer contract, and the > > >> > > > > persistence > > >> > > > > > contracts S88Repository, S88Storage and > > S88RepositoryProvider. > > >> > > > > > - /data : Serialization adapters implementing the contracts > > >> > above. > > >> > > > > > B2MMLRepositoryImpl parses/writes the main model using > > B2MML, > > >> > the > > >> > > > MESA > > >> > > > > > International schemas compiled with XMLBeans. > > AXMLRepositoryImpl > > >> > > > > > imports/exports the Rockwell FactoryTalk Batch .axml > > format. > > >> > > Formats > > >> > > > > are > > >> > > > > > pluggable: a new format is a new S88RepositoryProvider > > >> > discovered > > >> > > > > > through > > >> > > > > > NetBeans Lookup. > > >> > > > > > - /core : Application layer. A set of use cases (create, > > update, > > >> > > > > delete, > > >> > > > > > rename elements; manage class templates and struct > > entries) are > > >> > > the > > >> > > > > only > > >> > > > > > way to mutate the model. Every mutation fires an > > S88ChangeEvent, > > >> > > so > > >> > > > > the > > >> > > > > > UI > > >> > > > > > stays in sync. > > >> > > > > > - /plant : The NetBeans sub-project in charge of the plant > > >> > model's > > >> > > > > > lifecycle: project providers and factories, the hierarchy > > tree > > >> > > nodes > > >> > > > > > (one > > >> > > > > > per S88 level), project actions (import/export, templates, > > >> > > > > enumerations, > > >> > > > > > delete), and the shared panel/dialog builders reused > > across the > > >> > > > > > different > > >> > > > > > S88 levels. Loading and saving delegates to data > > repositories; > > >> > UI > > >> > > > > > refresh > > >> > > > > > is event-driven, not manual. > > >> > > > > > - /project : The NetBeans project type (wizard, factory, > > folder > > >> > > > > > installer, logical view) that hosts the plant sub-project. > > >> > > > > > - /batch : Placeholder module reserved for future recipe > > >> > > management > > >> > > > > and > > >> > > > > > supervision. > > >> > > > > > > > >> > > > > > The Process Cell config editor is intentionally empty; the > > >> > properties > > >> > > > > > dialog exposes only the General tab (name, level, class, > > display > > >> > > > > creation), > > >> > > > > > while content tabs (Attribute Tags, Parameters/Reports, > > >> > Arbitration, > > >> > > > > etc.) > > >> > > > > > are placeholders. These are the targets of upcoming updates. > > >> > > > > > > > >> > > > > > Recipes/batch supervision and generic ISA-88 runtime support > > are > > >> > > > outside > > >> > > > > > the scope of this PR (batch is a placeholder). > > >> > > > > > > > >> > > > > > Best regards, Daniel. > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > >
