Embedded Software & Enterprise Architect

The most important information in brief

How to model embedded software with Enterprise Architect?

When it comes to embedded software, modeling begins with the question of what information should be represented in the model and what role the model plays in the project. Enterprise Architect can be used as a tool to systematically capture software architecture, requirements, interfaces, states, workflows, and dependencies. For embedded systems, not only the source code is relevant, but also the interaction with hardware, communication interfaces, sensors, actuators, operating states, and overarching system functions.

PICKPLACE views modeling not as isolated drawing work, but as a technical structuring task. First, it clarifies which levels are needed: system context, software components, interfaces, data flows, state models, sequences, or behavior descriptions. This creates a model structure that fits the project questions. In an ECU project, for example, the focus may be on states, communication processes, and software components. For a machine, process chains, operating modes, fault reactions, and interfaces to operation, sensors, or drive technology may be the focus.

An essential work step is the separation between the architecture model, the detail model, and the documentation model. Not every detail of the source code belongs in the model. Conversely, an architecture model must not remain so coarse that it provides no usable information for development or testing. PICKPLACE supports finding the right granularity. This includes the decision of which components are managed as their own model objects, which interfaces are described, and which states or processes are mapped as diagrams.

Enterprise Architect can also be used to link requirements and architecture. This makes it possible to understand which software components address a requirement and which tests or analyses can follow. In projects with long lifecycles or multiple variants, this traceability is often a central part of the technical work. It helps to classify changes, identify impacts on other components, and avoid leading documentation completely separate from development.

For existing embedded software systems, reverse engineering can also be considered. This involves converting existing code or structural information into a model to visualize dependencies, classes, modules, or interfaces. While this does not replace architectural decisions, it provides a foundation for understanding and strategically revising existing software. PICKPLACE can set up and organize such models, supplementing them with architectural information, thus transforming a technical snapshot into usable project documentation.

When is model-based software development worthwhile?

Model-based software development is particularly worthwhile when embedded software needs to be maintained, expanded, or managed in variants over a longer period. For small, clearly defined software components, simple technical documentation may suffice. However, as soon as multiple teams, interfaces, product variants, or system levels are involved, coordination effort arises which becomes difficult to manage without structured models. In such cases, Enterprise Architect can serve as a common baseline for architecture, requirements, and technical relationships.

A typical trigger is a grown codebase. Many embedded projects evolve over years. Functions are added, interfaces change, hardware revisions switch, and individual software areas are adapted multiple times. If the architecture exists only in the source code or in the knowledge of individual people, changes become difficult to assess. Modeling can then help to make the existing structures visible and create a common basis for redesign, expansion, or error analysis.

Another project context involves highly complex systems. This includes control units, machine controls, vehicles, marine systems, and military electronics. In such systems, operating states, communication paths, error scenarios, and dependencies between software and hardware must remain traceable. A model can show which component performs which task, which data are transmitted via which interface, and how states change within the system. This facilitates technical discussions because decisions are not only made verbally or in scattered documents.

Even for projects with normative requirements or formal proof obligations, model-based work can be useful. The point is not to automatically fulfill a specific norm with a tool. The crucial aspect is that requirements, architecture, implementation decisions, and test references can be documented comprehensibly. Enterprise Architect can support this comprehensibility if the model is deliberately built and maintained. In such projects, PICKPLACE ensures that the model aligns with the actual development work and does not become a parallel documentation system that deviates from the project status after a short time.

The benefit strongly depends on the maintenance of the model. A model that is created once and not updated thereafter quickly loses its value. Therefore, at the beginning of a project, it should be clarified who is responsible for which parts of the model, which information is binding, and how changes will be incorporated. PICKPLACE supports this clarification through a model structure that considers roles and work steps. For development teams, this can mean regularly incorporating architectural decisions, interface changes, and state models. For testing and system engineering, the focus can be on links to requirements and workflows.

Model-based software development is not a substitute for domain analysis, clean implementation, or testing. However, it provides a level on which technical relationships can be described, verified, and coordinated with project stakeholders. Especially with embedded software that has a long lifecycle, this creates a basis for work that remains usable beyond individual development phases.

What are the benefits of good software architecture for maintenance, testing, and further development?

A good software architecture describes how an embedded software system is structured, what tasks individual components perform, and what interfaces exist between them. This description is practically useful for maintenance, testing, and further development if it answers concrete technical questions: Where is a function located? What dependencies exist on hardware, communication protocols, or other software parts? Which states influence behavior? What impact does a change have on adjacent components?

Maintainability is greatly improved by a well-documented architecture, especially when errors are not confined to specific components. In embedded systems, errors often arise from the interplay of state logic, timing, communication behavior, hardware states, and data processing. When the architecture makes these interdependencies visible, troubleshooting efforts can be more focused. Developers do not have to reconstruct solely from the code which component is responsible for which aspect of behavior. They can use architecture diagrams, state models, and interface descriptions as starting points for their analysis.

For testing, a modeled architecture creates a connection between requirements, system behavior, and testable software components. State diagrams can provide hints about which transitions need to be tested. Sequence diagrams can describe communication flows that are observed or stimulated during testing. Interface models show which data formats, signals, or messages should be checked in the interplay. PICKPLACE considers not only the creation of the diagrams but also their usability for test planning, review, and fault localization.

During further development, a clear architecture prevents changes from interfering with existing structures in an uncontrolled manner. When new functions are added, it must be recognizable whether they fit into an existing component, require a new component, or change existing interfaces. This question is particularly relevant for variants. A function can be present in one product variant, missing in another, or parameterized differently. Without an architecture model, such differences are often distributed via conditional compilation, configuration, or project-specific adaptations. A model can make variant points visible and support discussion about a suitable structure.

A good software architecture also helps with handovers. Embedded projects often span several years and change between development stages, teams, or responsibilities. If architectural knowledge exists only in individual minds, there is a risk of misunderstandings and long onboarding times during handovers. Well-maintained model documentation can provide the system structure, key design decisions, and interfaces in a form that remains comprehensible even later on.

For redesign or modernization projects, architectural work is often the first step before implementation. Before software is refactored, it must be clear which areas are to remain stable, which dependencies are critical, and which parts can be separated or restructured. Enterprise Architect can serve as a tool here to integrate existing structures from reverse engineering, inventory analysis, and expert assessment. This creates a basis for deciding which changes are technically feasible and achievable within the project scope.

Typical setup

• Requirements Tool Siemens Polarion
• Modeling tool Sparx Systems Enterprise Architect
• RTOS FreeRTOS
• Static Analysis Polyspace
• IDE IAR Embedded Workbench

Our Services

PICKPLACE supports projects involving Embedded Software & Enterprise Architecture with architectural work, model building, documentation, as well as forward and reverse engineering. The focus is on a model structure that aligns with the existing software, project goals, and involved roles.

At the beginning, we clarify which tasks the model should take on. This could be the description of a new software architecture, the documentation of an existing system, the preparation of a redesign, or the support of coordination between development, system engineering, testing, and the customer. From this, we derive which diagram types, model packages, abstraction levels, and links are needed.

In forward engineering, we support the development of architecture and model structures before or during software implementation. This includes defining components, interfaces, states, workflows, and dependencies. We ensure that the model prepares technical decisions and is not just a subsequent description. If requirements are to be incorporated, we structure the connections so that relationships between requirements, architecture, and potential test aspects become apparent.

In reverse engineering, we work with existing software versions or available technical information. The goal is to make structures visible that are present in the code, scattered documentation, or project knowledge. This can lead to models that serve as a starting point for analysis, error clarification, architecture revision, or documentation. Reverse engineering is not understood as an automatic solution, but rather as a technical entry point that must be technically reviewed and supplemented.

Another area of performance is model documentation. PICKPLACE creates and organizes model content so that it is usable for project stakeholders. This includes clear naming, comprehensible package structures, coordinated diagrams, and a documentation logic that fits development and handover processes. We also support in cleaning up, structuring, or updating existing models to a state that can be used for further project work.

In architecture development, we work on the functional and technical design of the software structure. This includes component breakdown, interface definition, state modeling, process description, and the classification of variants or existing dependencies. When a project is between analysis and implementation, PICKPLACE can help translate modeling content into concrete development tasks, verification questions, or documentation steps.