List of description methods from CPS PWG Cyber-Physical Systems (CPS) Framework
The object of interest/important characteristic is needed so that we can later say how to describe it—object of interest is reflected/framed by a viewpoint/description method. For example, the price::characteristic description method can be rules for composing estimates in rubles, or rules for specifying an arbitrarily defined price in dollars or "conditional units." This description method will need to be used so that the described object of interest (price) can then be discussed by different roles (seller and buyer) using it. Thus, the discussion about the price description method (how to model the price, how to describe it better, how to reflect knowledge about the price as a characteristic of the system) will differ from the discussion about the value of the price, that is, about "how to reduce the price" and "how to raise the price," although both of these discussions are significantly related (the choice of description method usually affects the negotiating position of one of the parties: different description methods are convenient for promoting different preferences).
And when we have just divided one complex discussion on an important characteristic into two simpler ones (by description method and by trading preferences), the task has become a bit simpler—this is the goal of system thinking. Among the concepts "method of work," "role," "object of interest," "preference," we need to add another concept: "method/approach of describing" (viewpoint).
Division in thinking of methods, performing their roles, objects of role interest, values of system characteristic preferences, description method of object of interest, and documenting the status of all these objects—simplifies maintaining attention in reaching agreements between roles in the project, making collective execution of projects to create systems easier.
After compiling a list of objects of interest/concerns and preparing descriptions/views based on agreed description methods/viewpoints, we cannot forget whose exactly these objects of interest belong to: the interests/preferences of different roles for the identified common objects of interest/characteristics may significantly differ, so the prepared system descriptions are only materials for discussions.
System thinking collectively—involves continuous alignment of preferences for a wide variety of characteristics, important to various project roles. System thinking is intended for structuring these discussions and requires distinguishing in them an actor, role, object of interest, interest/preference (where to move the characteristic, which state to prefer), description method, description, the value of the characteristic as a result of negotiating preferences.
In a public document (a public document differs from a standard only in that there is no procedure for checking compliance) CPS PWG Cyber-Physical Systems (CPS) Framework Release 1.0[1], a more complete table of objects of interest for cyber-physical systems is provided than in ISO 42010. In this public document (issued in May 2016) due to the long list of characteristics, they are divided into groups reflecting aspects: functional, organizational, human, trustworthiness, timing, data, boundaries, composition, lifecycle.
Aspects/areas of concerns/reflected interests reflect some content-related grouped objects of interest. The long CPS Framework table in the document looks like this (we will present its beginning and end):
![list-of-description-methods-from-cps-pwg-cyber-physical-systems-cps-framework-26.png]
How to use the table? This CPS Framework table works as a checklist: have you discussed all aspects/areas of interest of the systems (of interest system and creating systems) of your project, have you identified all objects of interest in them?
ISO 42010:2022 states that aspects are a reflection of "best practices" in what experts should be interested in their subject areas, it is easier to agree on less detailed objects of interest. These aspects only reflect the experts' opinion on what is important in the creation and development of some systems, and the "best practice" is the "best method of work" to date. The list of aspects from the CPS Framework was the "best" (although this could be disputed) in May 2016. Since then, instead of the term "life cycle," the concept of "creation and development of the system" is increasingly used, as a one-time development cycle from "birth to death" has been replaced by creating an MVP, that is, a minimal viable product, and subsequent continuous development without explicit consideration of the end of this development.
After finding objects of interest, you need to select a description method for each object of interest (referring to some standard or description method created and documented independently). Next, you need to determine where::software the various project roles can find up-to-date project documentation regarding the selected object of interest.
For example, for the functional area of interest (functional aspect), the functionalities of the target system (functionality) are vital. This is something you are unlikely to forget to investigate. In the systems engineering course, it will be stated about what a description (view) means—usage concept. But you must definitely go further: what will be the method of describing functionality? For small projects, you choose JTBD or customer journey, and for larger projects, use case 2.0. Now you need to document the selected description method and specify the location (modeler—and the address where the most recent versions of the functionality description will be stored). You will also have to answer questions like "if two teams of developers work on different use case scenarios and create independent modules to support them—is it one place or two?"
And these questions are asked for all other aspects (areas of interest) and for all key characteristics (objects of interest). For example, for the area of creating and developing systems (replacing the term "lifecycle" from the CPS Framework), choose the object of interest "operability". If you are a professional engineer, you know what should interest you there. If you are not a professional, you will be "reinventing the wheel." But better to reinvent the wheel than to forget! Warning: this is a very difficult issue! For example, you will have to somehow incorporate the digital twin into the considerations—isn't that precisely for improvements in operability? Now you need to choose a description method ("domain-specific language"/DSL/"modeling approach"/framework/ontology—either take from the literature, or create independently for project purposes). Define the software (not yours, but the agents who will somehow change these descriptions and look at these descriptions) as the place where the documented description will be stored. Then document this description, trying to consider all preferences regarding operability—and project roles (internal and external) will have a wide range of preferences. Make sure that this description is somehow realized, reflected in a physically embodied system (meaning not appeared internally documented but reflected what you described: embodying the described tractor—is not documenting the tractor description but making a working iron tractor). Do not deliberately generate disconnected from reality descriptions unless you are a science fiction writer.