BMW-ROOM An Object-Oriented Method for ASCET

This paper presents an object-oriented method customized for a tool-assisted development of car software components. Tough market conditions motivate smart software development. ASCET SD is a tool to generate target code from graphic specifications, avoiding costly programming in C. But ASCET lacks guidelines on what to do, how to do it, in what order, like a fully equipped kitchen without a cooking book. Plans to employ the tool for BMW vehicle software sparked off demand for an adequate, object-oriented real-time methodology. We show how to scan the methodology market in order to adopt an already existing method for this purpose. The result of the adaptation of a chosen method to ASCET SD is a pragmatic version of ROOM, which we call BROOM. We present a modeling guidebook that includes process recommendations not only for the automotive sector, but for real-time software development in general. The method suggests to produce early prototypes that are validated and refined to completion. BROOM offers phase-independent, harmonic guidelines. Product requirements, in form of scenarios, are transformed through several activities into operational models. BROOM takes advantage of ASCET’s rich experimentation- and code generation features. These allow to validate emerging models on button press. The factual development of a simplified heating/cooling system at BMW serves as a running example throughout the paper.

💡 Research Summary

The paper introduces BROOM, an object‑oriented, real‑time development method specifically tailored for the ASCET SD tool used in automotive software engineering. The authors begin by highlighting the pressure on automotive manufacturers to deliver increasingly complex electronic control units (ECUs) under tight cost and time constraints. While ASCET SD offers a powerful model‑based environment that can generate production‑ready C code from graphical specifications, it lacks a systematic methodology that tells engineers what to model, how to model it, and in which order. This gap is likened to a fully equipped kitchen without a cookbook.

To fill this gap, the authors first survey the landscape of existing real‑time object‑oriented methods, including OMT, UML‑RT, ROOM, and Rhapsody. They identify ROOM (Real‑Object Oriented Modeling) as the most suitable foundation because it provides a clear separation of concerns through actors, ports, protocols, and state machines, all of which map naturally onto real‑time control logic. However, ROOM was originally defined as a tool‑agnostic methodology, and its prescriptions do not exploit the specific capabilities of ASCET such as automatic code generation, built‑in simulation, and experiment‑driven validation.

Consequently, the authors adapt ROOM into a pragmatic variant called BROOM (BMW‑ROOM). BROOM retains ROOM’s core concepts but augments them with concrete, ASCET‑centric guidelines. The method is organized around a scenario‑driven workflow:

1. Scenario Capture – Customer requirements are expressed as concrete usage scenarios (e.g., “press temperature‑set button, system drives heater until target temperature is reached”). These scenarios are the source of both functional and non‑functional requirements (real‑time deadlines, memory limits).

2. Requirement Modeling – Scenarios are transformed into a traceable requirement model that records dependencies, priorities, and verification criteria.

3. Structural Modeling – Requirements are decomposed into actors (independent execution units) and ports (communication endpoints). Using ASCET’s graphical editor, developers place actors, define ports, and specify the protocols that govern inter‑actor messaging.

4. Behavioral Modeling – Each actor receives a state‑machine description that captures its internal logic. Events (button presses, sensor updates) trigger transitions, and ASCET’s simulation engine validates the behavior before any code is generated.

5. Prototyping & Early Validation – The structural and behavioral models are fed to ASCET, which instantly generates C code and a runnable simulation. Developers can interact with the prototype via virtual button presses or sensor injections, allowing rapid detection of design flaws without hardware.

6. Iterative Refinement – Feedback from the prototype drives model revisions. Because BROOM relaxes the strict sequential ordering of classic V‑models, developers may revisit earlier phases (e.g., modify the structural model after a behavioral test) without breaking traceability.

7. Final Implementation & Deployment – Once the model passes all validation steps, ASCET produces optimized production code that is loaded onto the target ECU. Automated checks verify that timing constraints (e.g., ≤10 ms cycle time) and resource usage meet the original specifications.

The authors demonstrate BROOM on a simplified heating/cooling control unit for a BMW vehicle. The functional scenario is broken down into three actors: a controller, a temperature sensor, and an actuator (heater/cooler). Ports are defined for command and feedback messages, and a state‑machine with states Idle, Heating, Cooling, and Error is constructed. Using ASCET’s built‑in simulator, the team validates that pressing the “set temperature” button correctly drives the heater or cooler, that the system reacts within the required real‑time deadline, and that error handling behaves as specified. The generated C code is shown to compile without manual intervention, illustrating the end‑to‑end flow from high‑level scenario to deployable software.

Key insights from the BROOM approach include:

• Prototype‑First Mindset – Early, tool‑driven prototypes dramatically reduce the cost of late‑stage redesigns.
• Tool‑Specific Guidance – By embedding ASCET‑specific modeling rules (e.g., how to map ports to generated interfaces), BROOM eliminates the ambiguity that typically hampers model‑based development.
• Flexibility Through Iteration – The method’s phase‑independent nature allows developers to respond to changing requirements without re‑starting the entire process.
• Maintainability – The clear separation of actors, ports, and state machines yields models that are easier to understand, extend, and verify over the long product lifecycle.

In conclusion, BROOM successfully bridges the gap between a high‑level object‑oriented methodology (ROOM) and a concrete model‑based development environment (ASCET SD). It provides a repeatable, scalable process that can be applied not only to the heating/cooling example but to a wide range of automotive ECUs, and potentially to other domains where real‑time constraints and code‑generation tools coexist. The paper suggests future work to extend BROOM to additional automotive subsystems (e.g., power‑train, ADAS) and to integrate it with automated test‑case generation and continuous integration pipelines, thereby further enhancing its applicability in modern, agile automotive software development.