Simply speaking, a solution pattern is a generic solution to a specific problem in a way that it can be repeatedly applied in different contexts, i.e. applications or use cases. It is based on practical experience and hence describes things that work.
Actually, solution patterns are systematic descriptions of working approaches in a generic way. To demonstrate their usability, each such pattern contains descriptions of its application in real use cases. A solution pattern can hence not be directly applied, but it is a principal description or template for how to solve a given problem. Its application in a real use case can be seen as (one of) its instantiation(s).
V&V-patterns are solution patterns that deal with effective validation, verification, and testing of complex systems, often safety-critical, and usually software-intensive. They address aspects such as when to test what, “coverage” – i.e. what features need to be covered, how to use formal verification effectively, or which kind of tools to use.
V&V-Patterns for ACPS
Finally, V&V-patterns for ACPS focus on aspects that are characteristic for (automated) cyber-physical systems: perception and recognition, behaviour and control, communication. The ECSEL-project ENABLE-S3 focused on just these topics, so the set of patterns described here have been elaborated in this project.
We use following items to describe V&V-patterns:
Pattern Name: A descriptive and unique name that helps in identifying and referring to the pattern.
Origin: Authors or persons who created that pattern
Purpose: A short description of the goal behind the pattern and a very short outline how it works.
Context/Pre-Conditions: Situations in which this pattern is usable.
To consider: Aspects to be considered when applying the pattern; they can help to decide about precise pattern application. Examples are required level of user knowledge, costs of involved tools (e.g.: if expert level is low, more expensive tools are needed).
Structure: A graphical representation of the pattern. A graphical flowchart or workflow diagram should be used for this purpose. In next clause, a simplified version of BPMN (Business Process Model and Notation / http://www.bpmn.org/) is presented.
Participants and Important Artefacts: A description of entities used in the pattern and their roles. Examples are humans, tools, data.
Actions/Collaborations: A description of what active entities do, and how entities used in the pattern interact with each other. Numbered items in the description should refer to numbers shown in structure diagram.
Discussion: Further information and hints, e.g.
Consequences: A description of the benefits, trade-offs, and drawbacks caused by using the pattern.
Comments: Further aspects like experiences valuable to be considered
Application examples: Examples of actual usages of the patterns, i.e. pattern instances.
Relations to other Patterns: Other patterns that have some relationship (e.g. Sub-/Super-pattern, Complementing, Conflicting) with the pattern, outlining the relationship.
As the last item indicates, solution patterns do not live in isolation; actually their real value emanates from their combined use. For instance, a step defined in one pattern could be refined by another pattern, or the outcomes of one pattern application will be used by another pattern. Thus, it is possible to concentrate on one approach in one pattern, while linking it to other solutions by referring to the corresponding other patterns. The large diagram on “V&V-patterns” page shows the most relevant relations among the V&V-patterns described there.
Patterns – History
The concept of solution patterns as used in ENABLE-S3 has been developed in the earlier ARTEMIS-project MBAT for describing generic solutions of “Combined Model-based Analysis and Testing of Embedded Systems”. You can find more information about them in the project outcome paper (https://vbn.aau.dk/ws/portalfiles/portal/208066749/RISK_Expressing_Best_Practices_final.pdf).