Good to see you again. You have now built the vocabulary needed to discuss a system from several angles: its boundary and environment, its life-cycle consequences, and the distinction among needs, requirements, functions, behavior, architecture, and design. This final lesson in the foundations module brings those ideas together in one compact embedded-system case.
We will use a rain-sensing wiper (RSW) controller: a sensor detects water on a windshield, software interprets the measurement, and an electronic control unit commands the vehicle’s wiper system. By the end, you should be able to explain this case in precise INCOSE-style language and identify how that explanation appears in a SysML/Cameo model.
Establish the system of interest before describing it
The same physical product can be viewed at several levels. For this lesson, define the system of interest as the rain-sensing wiper controller, not the entire vehicle.
The system of interest is therefore a system element within the larger vehicle system. At the vehicle-program level, the vehicle could instead be the system of interest and the RSW would be a subsystem. Neither choice is universally “correct”; the correct boundary is the one that supports the engineering decision being made.
The RSW’s purpose is to wipe the windshield automatically when liquid is detected, with wiper speed responding to the amount of liquid. It is a simple embedded system because it combines sensing, computation, embedded software, electronics, and interfaces to its operational environment.
Read the selected passages from the IBM Technical Report (2006). Its Rain Sensing Wiper case is a useful compact example because it connects system boundary, requirements, structure, interfaces, and behavior in one model.
In Section 2, “Context, Requirement and Use Cases” (PDF pp. 4–8), begin with the boundary discussion. Notice the distinction between actors and external systems. Then read the requirements introduction, focusing on why requirements are model elements rather than merely text in a separate document. In Section 3, “Structure of the Rain Sensing Wiper system” (PDF pp. 9–15), read the Block and BDD explanation. Continue with the IBD and interface explanation. Finally, in Section 4, “Behavior” (PDF pp. 16–22), read the behavioral-model introduction. Skim the subsequent state-machine and activity examples for their different purposes rather than trying to master every notation detail now.
Boundary, external systems, actors, and enabling systems
For the chosen scope, the principal system elements within the RSW include:
- the rain sensor;
- the electronic control unit (ECU);
- the embedded control software;
- mounting, electrical, and communication elements needed to make those parts work together.
Several important things are deliberately outside this system boundary:
| Item | INCOSE-style classification in this scope | Why |
|---|---|---|
| Windshield | External system element or interfacing external element | Its optical properties affect sensing, but it is not part of the RSW controller. |
| Wiper mechanism/interface | External system | The controller issues commands; the vehicle’s wiper mechanism produces motion. |
| Vehicle electrical system | External system | It provides power and may provide activation or status interfaces. |
| Driver | Stakeholder and operational actor | A person is not automatically a system element merely because they interact with the system. |
| Maintenance technician | Stakeholder and life-cycle actor | This person installs, diagnoses, calibrates, or repairs the system. |
| Calibration station and diagnostic equipment | Enabling systems | They support production, integration, service, and verification rather than delivering the RSW’s operational service. |
| Rain, temperature, contamination, vehicle vibration | Environmental elements and conditions | They constrain performance but are not necessarily systems with managed interfaces. |
An interface is the shared boundary across which elements exchange something or impose a constraint. The RSW has, for example:
- a power and activation interface with the vehicle electrical system;
- a measurement or optical interaction with the windshield and sensor;
- a command interface with the wiper mechanism;
- a human interface through driver activation or deactivation controls;
- a maintenance interface for configuration, diagnosis, or calibration.
A system boundary is not simply a box drawn around the components purchased from one supplier. It is a reasoned definition of responsibility, control, and analysis scope. The windshield is outside the RSW boundary, but it remains a critical interdependency: changing its thickness or optical characteristics can change the performance of the sensing function.
Explain the system through linked engineering artifacts
The terminology becomes clearer when each term answers a different question.
| Term | Question it answers | RSW example |
|---|---|---|
| Stakeholder need | What value or outcome is wanted? | The driver needs reduced manual workload while maintaining safe visibility in rain. |
| Requirement | What must the system do or be, under stated conditions? | “The RSW shall command an appropriate wiper mode when liquid detection exceeds the configured threshold.” |
| Function | What transformation or capability is needed? | Sense liquid, process measurement, select wiper command, issue command. |
| Behavior | How does the system act over time or in response to events? | The controller moves among deactivated, initializing, and activated states; it handles a manual disable command. |
| Architecture | How are elements, relationships, and interfaces organized to realize the system? | Sensor, ECU, software, vehicle-power interface, and wiper-command interface form an interacting arrangement. |
| Design | What specific realization is selected within the architecture? | A particular optical sensor technology, processor, software algorithm, mounting approach, connector, and calibration method. |
The sample requirement above is illustrative. In a real project, the team would need to define “appropriate,” threshold conditions, response time, failure behavior, environmental conditions, and verification criteria more precisely.
A frequent source of confusion is treating these terms as interchangeable:
- “Detect rain” is a function, not automatically a requirement.
- “The controller enters an initializing state at power-up” describes behavior.
- “Use a sensor, ECU, and wiper interface” describes an architectural arrangement.
- “Use this specified infrared sensor and this mounting adhesive” is a design decision.
- “The driver should not have to continuously adjust wiping in normal rain” is closer to a stakeholder need than a directly buildable requirement.
The transformation from needs to a realized system is iterative. Requirements inform architecture and design; analysis, testing, stakeholder feedback, and integration findings can reveal that a need, requirement, or architectural assumption needs refinement.
Hierarchy, interaction, and emergence
The RSW illustrates why systems engineers look beyond independently functioning parts. A sensor, ECU, windshield, and software configuration may all appear satisfactory when tested separately, yet the assembled system may fail to detect rain reliably.
The IBM case describes such an integration issue: a windshield with incompatible optical properties was combined with the sensor. The missing system-level concern was calibration and compatibility across the relevant sensor, windshield, and software characteristics.
This is an example of emergence. The desired property is not merely “the sensor works” or “the ECU runs software.” It is:
The integrated RSW provides dependable automatic wiping across the approved range of windshield and sensor characteristics.
That property arises from interactions among elements. It therefore needs system-level requirements, interface definition, integration planning, and verification—not only component specifications.
Express the same engineering story in SysML and Cameo
SysML does not replace systems engineering terminology; it gives that terminology explicit model elements and relationships. In Cameo, the model is the controlled set of elements and relationships. A diagram is a view of selected model content for a stakeholder concern.
For the RSW, a practical starting model could contain the following:
| Cameo/SysML model content | Engineering meaning |
|---|---|
| Requirement diagram | Captures stakeholder and system requirements, their decomposition, derivation, and rationale. |
| Block Definition Diagram (BDD) | Defines blocks such as RainSensingWiper, Sensor, ECU, and external interfacing blocks. It expresses classification and structural decomposition. |
| Internal Block Diagram (IBD) | Shows part usages, ports, connectors, and flows inside the RSW boundary and across its interfaces. |
| Use case diagram | Identifies externally visible interactions, such as automatic wiping, manual deactivation, and maintenance. |
| State machine diagram | Shows modes and event-driven transitions, such as Deactivated, Initializing, and Activated. |
| Activity diagram | Shows the functional flow: sense, process, decide, and command. |
| Test case / verification relationship | Connects a verification case to the requirement it is intended to verify. |
In the model, a «satisfy» relationship states that a design, structural, or behavioral element is intended to satisfy a requirement. A «verify» relationship connects a test case or other verification element to the requirement it checks. These relationships support traceability, but they do not by themselves prove that the requirement has been met. Verification evidence is still required.
The next resource shows this pattern in Cameo with a more complex medical-device example. Its important lesson is the separation of concerns: requirements, behavior, and structure are related, but they are not the same model view.
Systems Engineering in a Time of Social Distancing – Part 2a: Ventilator SysML Model (Cameo)
Read the focused Cameo examples from Intercax. The ventilator is more complex than the RSW, but its model organization demonstrates the same disciplined connection among requirements, behavior, structure, interfaces, and verification.
In the introductory discussion before the “Requirements” subsection, read the model scope statement. It is a useful reminder that an illustrative model is not automatically a validated design. In the “Behavior” subsection, read the behavior passage. Focus on the distinction between operating modes in a state machine and lower-level actions in an activity. In the “Structure” subsection, read the structure and interface passage. Relate its decomposition and IBDs to the RSW’s sensor, ECU, software, and vehicle interfaces.
This distinction is worth making explicit:
- A BDD answers, “What kinds of blocks and structural relationships exist?”
- An IBD answers, “How do these particular parts interact through ports and connectors?”
- A state machine answers, “What states can an element occupy, and what events cause transitions?”
- An activity diagram answers, “What actions and flows realize a function?”
- A requirement diagram answers, “What obligations exist, and how are they related?”
Do not put everything onto one diagram. A well-organized Cameo model uses several views, each addressing a particular concern while preserving relationships across them.
A concise INCOSE-style explanation of the RSW case
Use the following as a pattern for an exam response, a technical review explanation, or a first model description:
The system of interest is the rain-sensing wiper controller, an embedded system element within the larger vehicle system. Its operational purpose is to support automatic windshield wiping by sensing liquid conditions and commanding the vehicle wiper system. The controller contains a sensor, ECU, embedded software, and associated internal interfaces. The windshield, vehicle electrical system, wiper mechanism, driver, and maintenance organization are outside the controller boundary, although they are critical external systems, stakeholders, or environmental elements. Production calibration equipment and diagnostic tools are enabling systems because they support realization and sustainment rather than normal wiping operation.
A stakeholder need for reduced driver workload and reliable visibility is transformed into system requirements for automatic detection, command behavior, manual override, environmental compatibility, and calibration. The controller performs the functions of sensing, processing, deciding, and actuating. Its behavior includes initialization, active automatic control, and deactivation states. Its architecture allocates these functions across the sensor, software, ECU, and external interfaces. Specific choices of sensor technology, algorithm, mounting, and calibration approach are design decisions. System-level performance emerges from the interaction of sensor, windshield, software, and ECU; therefore interface compatibility and calibration must be addressed by requirements, architecture, integration, and verification.
Common terminology errors to avoid
-
Calling every external item an external system
Rain, temperature, and vibration are environmental conditions. The driver is a stakeholder and actor. A windshield or vehicle electrical system may be an external system because it has a defined relationship and interface with the RSW. -
Calling a function a requirement
“Sense liquid” names a function. A requirement specifies an obligation, conditions, and often measurable criteria. -
Treating the architecture as a parts list
Architecture includes elements and their relationships: allocation, interfaces, flows, and organizing principles. -
Treating a component test as proof of system performance
The calibration failure shows why individually conforming components do not necessarily yield a conforming integrated system. -
Assuming system boundaries are permanent
The RSW is the system of interest for this lesson, but it is also an element in the vehicle. Scope depends on the decision context.
Key takeaways
A precise systems-engineering explanation begins by stating the system of interest and its boundary. It then distinguishes internal system elements from external systems, stakeholders, environmental conditions, and enabling systems.
For the rain-sensing wiper, stakeholder needs lead to requirements; requirements motivate functions; behavior describes response over time; architecture organizes elements and interfaces; and design selects specific realizations. The system’s reliable automatic wiping is an emergent property of interacting sensor, windshield, software, ECU, and calibration decisions.
In SysML/Cameo, requirements, blocks, interfaces, states, activities, and verification cases provide connected but distinct model views of that engineering argument.
Next, the course moves into life cycles, process logic, and tailoring: how systems-engineering work is organized over time, iterated, and applied recursively across system hierarchy.
Can't find a good explanation? Sign up and we'll make it for you
Sign up