Platform Independent Models (PIMs)

• Platform Independent Models (PIMs) are abstract blueprints that define a system's structure, logic, or behavior without reference to specific implementation platforms.
• They utilize meta-models such as UML and DSLs to capture essential components, actions, and interconnections in fields like robotics and software architecture.
• Transformation pipelines map PIMs to platform-specific models through code generation, automata reification, and binding techniques while ensuring type safety and behavioral consistency.

A Platform Independent Model (PIM) is an explicit, technology-agnostic representation of a system’s structure, logic, or behavior that omits all references to specific implementation platforms such as programming languages, operating systems, or hardware APIs. PIMs serve as central artifacts in Model Driven Architecture (MDA) and related paradigms, enabling maximal reuse, separation of concerns, and formal transformation to platform-specific implementations (PSMs). They appear in various forms across robotics, automation, and software architecture, unifying methodologies that aim to decouple system logic from deployment constraints (Reckhaus et al., 2010, Butting et al., 2016, Dayan et al., 2020, Ringert et al., 2014, Ringert et al., 2015).

1. Foundations and Definitions

PIMs function as precise yet abstract blueprints for systems:

• In model-driven robotics, a PIM encodes robot control or assembly logic (action sequencing, data flow, state transitions) abstracted from all platform mechanisms (Reckhaus et al., 2010, Butting et al., 2016).
• In component & connector (C&C) architectures, a PIM specifies component types, their ports/interfaces, interconnections, and—for fully modeled parts—their behavior automata, while omitting all platform or middleware details (Ringert et al., 2014, Ringert et al., 2015).
• In execution semantics, the PIM can be formalized as a tuple or automaton structure: e.g., the AMDA approach represents each system object as a Parallel Hierarchical Sequential Automaton (PHSA), which captures states, transitions, memory, guards, and I/O abstractly, for later systematic mapping to code platforms (Dayan et al., 2020).

Across these domains, PIMs delineate clear extension points—such as “abstract components” in software architectures or “actions” in robotic control sequencing—which will later be realized with platform‐specific code or libraries.

2. Meta-Models and Structural Characterization

PIMs are always grounded in a meta-model, typically articulated in UML, abstract syntax trees, or domain-specific languages (DSLs):

• Robotics PIMs (as in (Reckhaus et al., 2010)): Meta-models define primary entities such as ResourceComponent (scheduling domains), Action (parameterizable atomic activity), and Variable (data slots). Instantiation occurs via platform-independent DSLs, often XML-based, which specify concrete actions and resources available for a family or class of robots.
• Software C&C PIMs (Ringert et al., 2014, Ringert et al., 2015): The meta-model comprises ComponentType (with ports, parameters), composition hierarchies, connectors, and optionally embedded automata as behavior models. Abstract and fully-modeled variants are distinguished, with only abstract types awaiting later binding.
• Hierarchical Process PIMs (Butting et al., 2016): Architectures such as LightRocks assign layers—AssemblyPlan, Process, Task, Skill, Action—each with explicit separation between domain-level modeling and platform-specific implementation points. Grammar fragments and UML diagrams define the structure.

Aspect	Robotic Control PIM	C&C Architecture PIM	Hierarchical Process PIM
Top-level Elem.	ResourceComponent, Action, Variable	ComponentType, Connector, Behavior	Plan, Process, Task, Skill, Action
Behavior Model	Action dependency graphs	Automata or abstract/no behavior	Statecharts from processes/tasks/skills
Extension Pt.	DSL-defined Actions/Resources	Abstract Component Types	Actions (lowest level)

All meta-models rigorously ensure that no direct reference to platform APIs, GPLs, or runtime environments exists at the PIM level.

3. PIM Transformation and Mapping Mechanisms

The transformation of PIMs to platform-specific models (PSMs) or code proceeds via explicit, type-checked pipelines:

• Template-based Generation: In robot control sequencing (Reckhaus et al., 2010), the abstract action graph is traversed topologically; code templates (e.g., in Velocity) are filled in per resource/action to generate code for environments such as MSRDS or NXC.
• Statechart Mapping: In LightRocks (Butting et al., 2016), PIM process/task/skill graphs are mapped to nested UML-style statecharts. Code generators target languages such as Java or C++, with transitions and state logic realized in the runtime environment.
• Automaton Reification: AMDA (Dayan et al., 2020) builds the PIM as a parallel collection of PHSA automata, stores them in XML, and applies XSLT-driven transformations to realize PSMs for Java, C#, or other targets. Types, memory, and I/O are translated per platform mapping functions.
• Component Binding: In C&C architectures (Ringert et al., 2014, Ringert et al., 2015), an explicit binding transformation replaces each PIM abstract component instance with a reference to a concrete platform-specific implementation (via an application configuration file). Type inheritance, interface compatibility, and generator/runtime environment constraints are strictly enforced.

The generalized transformation pipeline is:

1. Parse and validate the PIM and any external configuration/binding models.
2. Build enriched ASTs or intermediate representations that annotate or substitute platform-specific elements.
3. Invoke code generators or interpreters parameterized by platform, emitting code or execution artifacts for the target environment.
4. Preserve the PIM logic (sequence, control, behavior) across platform instances by construction.

4. Separation of Concerns and Reuse

A defining feature of PIM-oriented development is the explicit separation between domain logic and platform implementation, usually enforced at the modeling tool and meta-model level:

• In LightRocks (Butting et al., 2016), domain experts construct Processes and Tasks using domain vocabulary and abstractions, insulated from API calls or low-level control. Robotics experts supply Skills and Actions encapsulating all direct hardware interaction.
• C&C approaches (Ringert et al., 2014, Ringert et al., 2015) distinguish between platform-neutral architecture (PIM, with abstract and composed components) and implementation libraries for each target platform. The same logical architecture (e.g., BumperBot on NXT/leJOS or ROS/Python) is reused by switching application configurations and binding files.
• Robotic action sequencing (Reckhaus et al., 2010) allows the same platform-independent control graph to be realized across robots and programming environments by reusing action semantics and changing the code template or DSL.

This enables:

• Complete reuse of core system models across platforms.
• Avoidance of duplicated designs, accidental complexity, and maintenance overhead.
• Incremental adaptation to new platforms by only extending or swapping platform-specific artifacts.

5. Formalism and Verification

PIMs in advanced settings employ formal constructs for precise semantics and verification:

• Automata-based PIMs (AMDA, (Dayan et al., 2020)): PIM state and transition logic is directly formalized as tuple structures with OCL guards and memory mappings. The approach preserves statechart hierarchy and concurrency semantics, supporting traceable transformations.
• Type Safety in Binding: C&C transformation schemes (Ringert et al., 2015) involve rigorous type-inheritance checks $T_{ps}\sqsubseteq T_{abs}$, signature conformance, and configurable argument propagation. Rewrite rules and pseudocode algorithms (e.g., “BIND” procedure) operationalize the transformation.
• Side-effect Constraints: In parallel action PIMs (Reckhaus et al., 2010), not-simultaneous relationships and scheduling constraints are declared in the DSL. Graphical tools enforce these statically, preventing concurrency races at the PIM level.
• Well-formedness Guarantees: All frameworks enforce interface and port type validation at bind-time, and check that each PIM can be realized and refined for the chosen target platform.

Model checking and contract-based refinement (assume/guarantee synthesis) are seen as open directions for more rigorous PIM validation (Ringert et al., 2014).

6. Applications and Case Studies

Multiple domains demonstrate the effectiveness of PIMs:

• Robot Control (Reckhaus et al., 2010): Service robots and educational robots (Lego NXT) use platform-independent PIMs for action sequencing, generating platform-targeted code via code templates; the same control logic serves multiple robot classes.
• Assembly in Smart Factories (Butting et al., 2016): Modular robot assembly plans expressed as PIMs are reused across compliant robots by binding only at the action (API) layer; domain and robotics experts work independently.
• Software Architectures (Ringert et al., 2014, Ringert et al., 2015): Logical architectures (e.g., BumperBot, Robot Explorer) are deployed to NXT/leJOS and ROS/Python platforms, with 100% of the architecture model reused and adaptation restricted to small binding files. Maintenance benefits include avoidance of duplicate model code and minimized adaptation effort.
• Automata-based Systems (Dayan et al., 2020): ATM controllers and similar reactive systems are modeled as platform-independent automata with state memory and I/O, later mapped precisely to Java or C# for execution.

7. Limitations, Open Issues, and Future Directions

Identified limitations across frameworks include:

• Expressiveness and Scalability: Synchronous/parallel task execution and model editor performance for large models are points for improvement (Butting et al., 2016).
• Binding Flexibility: Current binding mechanisms are usually unconditional, lacking support for conditional or bulk (pattern-based) bindings (Ringert et al., 2014, Ringert et al., 2015).
• Behavioral Contract Enforcement: Most PIM-to-PSM approaches ensure syntactic interface compatibility; they do not formally guarantee that PSM behavior refines or is trace-consistent with PIM logic. Work on assume/guarantee contracts and semantic matching is planned (Ringert et al., 2014).
• Connector and Wiring Adaptation: Adapting port/connector wiring in the platform-specific realization is not systematically supported (Ringert et al., 2015).
• Meta-Model Evolution: Extending meta-models to capture dynamic planning, environment modeling, or advanced UML constructs (activity diagrams, composite structures) is under ongoing research.
• On-line Model Editing: Live editing and model adaptation during deployment is not supported in most current toolchains (Butting et al., 2016).

A plausible implication is that future methodologies will incorporate richer variation points, dynamic adaptation, expanded formal analysis capabilities, and more flexible integration with code generators and verification frameworks.

---

References:

• (Reckhaus et al., 2010) Reckhaus et al., "A Platform-independent Programming Environment for Robot Control"
• (Butting et al., 2016) "Modeling Reusable, Platform-Independent Robot Assembly Processes"
• (Dayan et al., 2020) "MDA Models and PIM/PSM Transformations Using Extended Automata"
• (Ringert et al., 2014) "Multi-Platform Generative Development of Component & Connector Systems using Model and Code Libraries"
• (Ringert et al., 2015) "Transforming Platform-Independent to Platform-Specific Component and Connector Software Architecture Models"