Concept of a design activity supporting tool in the design and development process of cyber physical system

ABSTRACT

Cyber-Physical Systems (CPS) are systems that link cyberspace with the physical world by means of a network of interrelated elements (sensors and actuators) and computational engines. These different assets make it difficult to design properly and effectively with them all. Additionally, the designing of CPS requires multi-disciplinary project teams and the investigation of all activities which CPS should perform. The designers have to share their knowledge, experience and identify the assets and activities which are necessary for proper CPS functioning. The proper identification process of CPS activities allows improvement of the design process through more precise and problem-activity-dedicated knowledge and activity-design models management. This process can also be supported by dedicated software tools which enable easy access to the acquired and accumulated knowledge.

KEYWORDS:

• CPS
• knowledge modelling
• assisting systems in engineering
• design supporting software

1 Introduction

Designing CPS-class systems and machines with CPS elements is a relatively new area of research. Although many papers can be found in the literature related to this subject, e.g. (Alguliyev, Imamverdiyev, and Sukhosta. 2018; Gupta, Yagnyasenee, and Shyamapada 2018; Kan, Anumba, and Messner 2019; Darwish and Hassanien 2018; Pokojski, Knap, and Trojgo 2019A; Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Liu, Zhang, and Cao et al. 2020), the majority of them concern the perspective narrowed down to a specific class of cases or solutions e.g. (Kan, Anumba, and Messner 2019; Knap 2017). Relatively few of them propose more general and universal approaches (Hehenberger et al. 2016; Darwish and Hassanien 2018; Pereira Pessôa and Jauregui Becker 2020; Da Silva et al. 2020; Hansen and Bøgh 2021; Xu, Xu, and Li 2018; Pereira, Szejka, and Canciglieri Junior 2021; Lim, Zheng, and Chen 2020).

Also, some of them concentrate on the requirement that methodologies for CPS-design should be part of a multi-disciplinary development process within which designers focus not only on the separate physical and computational components, but also on their integration and interaction (Pokojski, Knap, and Trojgo 2019A; Pokojski 2004, 2017; Liang and Guodong 2006). Other authors, in the process of designing CPS, focus on how to model and design the joint dynamics of software, networks, and physical processes (Knap 2017; Carreira, Amaral, and Vangheluwe 2020).

The authors of this paper worked on developing a functioning industrial project, the aim of which was to design a specific technical system with CPS elements – a tractor electronic transmission control unit (TCU) which, as well as controlling the gear shifting process, is also responsible for the control of almost all main functionalities of the tractor (e.g. braking, automatic tool lifting, telemetry). The project was started using classical design methods. In the course of the project the authors observed that this approach in a multidiscipline environment was not sufficiently productive, and thus a process-oriented approach was applied (Monticolo et al. 2015; Stjepandic, Wognum, and Verhagen 2015; Sobieszczanski-Sobieski, Morris, and van Tooren 2015), which generally focused on the analysis of functionalities needed to be implemented in TCU, required assets event scenarios, and risk. During the project many of the design activities evolved considerably due to emerging problems, extending knowledge, and the gaining of new experience by the project team members.

The identification of functionalities implemented by TCU allows the definition of tasks and resources, as well as the gathering of the necessary knowledge to solve initially identified design problems. But attention has to be paid not only to the design process itself, (product models, requirements and constraints, aspects of analysis and synthesis, automation tools, and the wider contexts of particular issues,) but also to the identification of design activities (performed by human designers) and the requirements related to them.

The proper identification process of CPS activities (Ferguson, Kasprzak, and Lewis 2009) allows improvement of the design process through more precise and problem-activity-dedicated knowledge, and activity-design models management. It is also important to take into account the fact that activities realized during the project may significantly evolve over time, and it is beneficial to maintain sets of different versions of solutions to particular problems. Effective knowledge management accompanying the evolution of an activity may be supported by a properly designed software tool which may lead to the automation of the realization of selected activities.

One of the conclusions was the suggestion that the whole design process needs to be improved by creating a concept and then building a dedicated environment supporting this class of tasks in the following areas: informal and formal knowledge consolidation/storage/management (Chandrasegaran et al. 2013), creation and simulation/analysis of CPS models (Kan, Anumba, and Messner 2019; Darwish and Hassanien 2018), supporting decision-making processes in design using the multidisciplinary design approach applied in a selective way (Pokojski 2004; Pokojski, Knap, and Trojgo 2020; Nomaguchi and Fujita 2013).

The goal of the work carried out over a longer period was to create the concept of assisting software for designers (Baxter, Gao, and Case et al. 2007). This software strives to support the design process of a product treated as CPS (Chandrasegaran et al. 2013; Safavi et al. 2015). It was assumed that an assisting system allows design knowledge management at both the elementary level and at the level of entire classes of typical knowledge elements, or classes of elements requiring certain adaptive actions offering moving away from stereotypical design solutions (Balesdent et al. 2012; Curran et al. 2010; Duddeck 2008; Ferguson, Kasprzak, and Lewis 2009; Pokojski, Oleksiński, and Pruszyński 2019c).

In this work the authors undertake an attempt to create such a concept of a supporting tool primarily based on information and knowledge from a real-life project.

To summarize, the purpose of the research presented in this paper is aimed at developing a concept of a method whose implementation would make the process of designing CPS or systems with CPS elements more effective and more intuitive for designers. The notion of the design activity has been taken as an important reference point – which in a real design process is very often used by designers to indicate fragments of the design process needed to be discussed, implemented, changed and which is generally evolving in time.

The authors have analysed the evolution of selected design activities in a real design task of CPS. First of all, the evolution of knowledge related to each specific activity has been analysed – both the substantive aspect and structural changes have been taken into account. Based on this information, an attempt was made to develop a template-based approach that would allow formal and effective modelling of such an identified process.

The conducted research represents the first iteration resulting from the analysis of a real project task of CPS. It can provide a starting point for further research. At the same time, it should be noted that CPS design processes (at their current stage of development) are characterised primarily by a broader substantive scope and more intensive evolutionary changes compared to classical design. Therefore, improving the efficiency of these processes, carried out in interaction with the designer, seems to be very important at the present time.

2. Characteristics of the analysed project task

The case analysed in the present work is the process of designing a transmission control unit (TCU) also performing the control and monitoring of a particular tractor operation. The transmission system consists of a mechanical system (semi-automatic transmission, drive system, brake system, tool handling system) controlled and managed with the developed electronic system. These systems are additionally connected with multiple sensors and actuators. All these components are controlled by dedicated software and composed into the designed CPS.

The project was developed by a company carrying out specialized projects for a tractor manufacturer. The tractor manufacturer has developed a new generation transmission for an agricultural tractor. The main component of the transmission is a section with 4 gears switchable under load and with forward/reverse gears. All these gears (as well as the PTO drive, front drive, and differential lock) are controlled by switching on/off the wet multi-plate clutches controlled hydraulically by means of electromagnetic proportional valves controlled by the designed TCU. The transmission is also equipped with a whole range of other functionalities like brakes, 3-point tractor hitch, etc. The TCU is also responsible for monitoring the transmission, and collecting, archiving and presenting information on three different levels of detail to the operator, service, or manufacturer.

3 Characteristics of the design process – the perspective of the task being analysed

3.1 General problem structure

In fact, when the TCU design task and the process of solving it is analysed, it is very difficult at the beginning to capture its real scope, available sources of knowledge and models (Stjepandic, Wognum, and Verhagen 2015). Usually, it is possible to see the basic requirements and identify functionalities. But the process of checking individual requirements and characteristics takes place in the range initially perceived. The problem is decomposed, and specialists dealing with individual partial tasks are separated. Usually, they work individually or in small sub-teams. They use their knowledge, and their own and other available models and tools. The partial results obtained are confronted and compared. As a result, it can be seen that initially, elementary design-decision problems are modelled (each of them engages 1–2 people). Rational solutions are noticeable for these small tasks. Different approaches are used: mental simulations (Darwish and Hassanien 2018), checking constraints, attempts to apply solutions typical for the case-based reasoning method (Pokojski 2004; Darwish and Hassanien 2018) (and similar or simpler versions of it) and multi-disciplinary optimization methods (Sobieszczanski-Sobieski, Morris, and van Tooren 2015; Pokojski, Knap, and Trojgo 2020; Nomaguchi and Fujita 2013). Starting such a task, usually the person in charge of solving the problem estimates (the estimation is based on his/her knowledge and intuition) the potential of such a problem, the level of its solvability, the adequacy of the methods and the tools which are used (Pereira Pessôa and Jauregui Becker 2020; Da Silva et al. 2020; Hansen and Bøgh 2021; Xu, Xu, and Li 2018; Pereira, Szejka, and Canciglieri Junior 2021).

The next stages are quite structurally (and tool-related) similar to the previous ones. They are only carried out at higher levels of complexity. Concepts that go beyond the standard functionalities appear somewhat separately, i.e. where it comes to sensing certain and typical states, the awareness of which requires models, a certain inference, and the adoption of a sensible response strategy (Kan, Anumba, and Messner 2019; André et al. 2017; Monticolo et al. 2015). It is basically a group of design processes that concentrates on finding specific knowledge, which in a computer-modelled form can interact with a mechanical system to form a problem-oriented CPS subsystem.

3.2 Diversity and complexity of considered problems

The subject of the design process may be products of varying degrees of complexity (Nomaguchi and Fujita 2013). They can be classic products, classic products equipped with automation systems, mechatronic systems, or systems based on CPS concepts. In general, it can be concluded that CPS systems are the most complex structures that, apart from those aspects that occur in classical design, may contain new components resulting from monitoring, control, etc., as well as the detection of various other circumstances that mean awareness of certain phenomena that allow us to initiate and control the functioning processes of relevant computer models. The considered case study of the TCU design is a problem of designing the structure of the CPS system with all its diversity and complexity aspects.

The analysis of the literature on the issues of CPS design processes leads to the conclusion that there are numerous different structures of those processes in practice (Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Liu, Zhang, and Cao et al. 2020; Amir and Givargis 2020). They usually consist of many interrelated problem models, often located in different disciplines of knowledge. Their integration and information flows are also characterized by a high level of model diversity, on the one hand resulting from the lack of commonly accepted methodology, and on the other hand, from basing them on solutions, as well as using solutions which were proven in other design processes. The way usually used in analyses of this class of problems is far-reaching formalization – creating and operating on a large number of often interdependent complex formal models. Not only attempts at implementation, but even the classification of this class of solutions reveals the enormity of work that is associated with the construction and analysis of the models used in them (Pereira Pessôa and Jauregui Becker 2020; Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Liu, Zhang, and Cao et al. 2020). Not only can the models themselves be complex, but also the processes of the identification of structures and parameters, the processes of multi-scenario selection of controls and multi-stage strategies, the processes of monitoring the correctness of operation and diagnosing failures, etc.

The complete analysis of the design problems characterized above requires a lot of effort to model and obtain large numbers of necessary data for them. This is not always possible, easy or rational. Another clearly scarce resource is knowledge related to the realization of such problems. The complexity of formalization with CPS design processes neither guarantees high quality of the obtained results and high potential of the proposed solutions, nor short time to obtain a satisfactory solution. This complexity is generally not equivalent to model excellence.

This situation resembles the problems of applying a multi-discipline approach (design/optimization) in areas where this approach has not been applied before (Stokes 2001; Biffl, Luder, and Gerhard 2017; Safavi et al. 2015; Yi, Shin, and Park 2008). It happens then that great expense does not bring the expected results. However, it can be concluded that in most successful applications of a multidisciplinary approach, success was preceded by a long period of experimentation with various possible, generally well thought-out solutions (Li et al. 2017; Lee, Choi, and Lee 2020; Sim and Duffy 2003; Pahl and Beitz 2007).

CPS design processes are in most cases similar to the concept of multi-discipline design, only with a much larger range of considered problem solution classes. To solve this class of problems it is most sensible to start with narrow, priority issues for a given project for which there are already some initial knowledge resources available. The next step is to try to modify or expand this knowledge and verify it. These activities should have strong expertise support from many disciplines (Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Liu, Zhang, and Cao et al. 2020). A very important element is the precise articulation of boundaries and scopes of work – although these boundaries and scopes often expand considerably as the design process progresses (Da Silva et al. 2020).

In order to formalize the definition of borders and ranges, a template concept can be used, with which only those elements from the whole realizable models of design problems in CPS may be considered that were subject to the modification, bring good results, and promise further actions (Chandrasegaran et al. 2013; Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Liu, Zhang, and Cao et al. 2020; Amir and Givargis 2020; Da Silva et al. 2020). Further, the whole concept can be developed in an evolutionary way by means of the gradual improvement of the key, or the substantially most important issues. In this sense, templates are units of tools supporting design work. Their use results from the experience and effectiveness of mostly transdisciplinary, expert and partly automatic problem-solving strategies – set in the hierarchy of importance. They can also be integrated in a way typical for multidisciplinary design.

The preliminary observation of the process of designing the example CPS system realized in this paper supports the intuitively created (in the solved task) hypothesis about the asymptotic approach leading to effective global solutions of the whole problem through a sequence of macro design steps (supported by evolutionary modified templates).

This approach is not new in technology – it resembles the actions realized realistically in engineering processes over quite long periods of time (Hansen and Bøgh 2021; Xu, Xu, and Li 2018). It is criteria-based, multi-stage knowledge development. Our proposal uses tools that allow the exposure and capture of the elements of this knowledge evolution, and then the modelling, storage and re-use of it. As a consequence, the whole process of the project task has to be made faster and more efficient by focusing on key problems (and opportunities). Templates are convenient units for the consolidation of problem-oriented engineering knowledge, across different disciplines, with different levels of formal advancement, which can gradually evolve with the maturity of the design process or its organization.

4. The concept of an assisting tool

4.1 Block/template structures

The material obtained in the analysed example was used to create the concept of an assisting system in the design process of the product with CPS or its elements. The proposed concept is based on the creation of the possibility of modelling individual project activities and their evolution using templates (Chandrasegaran et al. 2013; Nomaguchi and Fujita 2013; Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Amir and Givargis 2020; Zhenjun et al. 2019; Pokojski, Oleksiński, and Pruszyński 2019b, 2019c). The template representing a specific activity is to serve as a repository in which it is possible to store the informal model of the given activity as well as its formal model (Zhenjun et al. 2019; Pokojski, Oleksiński, and Pruszyński 2019b, 2019c; Amir and Givargis 2020). Both variants of the knowledge model can be stored within the same version of the template. Another element of the template involves the decision-making models of given activities: the problem of selection on the basis of requirements, by the case-based reasoning (CBR) method, and classical inferencing and formalisms based on optimization methods (Balesdent et al. 2012; Arthur 2009). The concept introduces the possibility of combining decision-making formalisms as often occurring in real terms, eg. combining CBR and optimization, etc. Additionally, in the template it is possible to store information on sources of knowledge related to particular components of a given template (Darwish and Hassanien 2018; Safavi et al. 2015; Balesdent et al. 2012; Curran et al. 2010; Duddeck 2008; Ferguson, Kasprzak, and Lewis 2009; Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017).

The presented concept of the template comes from the works (Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017). It is based on an approach known from the concept presented in MOKA methodology (Stokes 2001; Amir and Givargis 2020). The template is basically a model of a certain process during which the informal knowledge is transformed (converted) into a formal form. The content of the template can be used at any level, from informal (while creating the possibility of occurrence in many stages of development) to formal (also when creating the possibility of occurrence in many stages of development). Modelled knowledge resources can, depending on their form, be used as a kind of descriptive information intended directly for people as well as computerized automatic tools such as KBE (Knowledge Based Engineering) (Pokojski, Oleksiński, and Pruszyński 2019b, 2019c; Pokojski, Knap, and Trojgo 2020; Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017; Liu, Zhang, and Cao et al. 2020; Amir and Givargis 2020).

This concept, implemented in the form of a whole set of activities, allows the building of the processing based on different levels of built models. One can act only on descriptive models, and gradually lead the process of transitioning to the level of automatic tools with different degrees of perfection. In general, the financial rationality of the whole approach strongly specifies this solution. The construction of a complete automatic environment from the beginning is very complex and expensive. It is accompanied by quite a significant level of risk. The proposed evolutionary procedure gives the opportunity to rationalize the entire process.

4.2 General structure of assisting system

The concept of the system consists of two parts: “human way of problem modelling“, ”model-based problem solving”. The first deals with the consolidation of informal knowledge and gradually emerging formal knowledge elements. The second includes formal models, their quickly re-modellable forms concerning both analyses, simulations, and decision modules. It is based on blocks/templates.

The formalism provides the possibility of integrating a set of model-related activities – the so-called partial models, both in their substantive and decision-making layers, into larger entities called blocks.

CPS systems can have a whole range of references resulting from their structure, implemented in the form of modelled views. These are: object layer, sensing layer, communication layer, analysis layer, and actuator layer (Kan, Anumba, and Messner 2019; Darwish and Hassanien 2018; Chandrasegaran et al. 2013). The main task of the tool with the presented concept is to improve the design process through more precise and problem-dedicated knowledge management and applied design models.

5. Design activity modelling

5.1. Real-life project inspirations

As already mentioned, the authors decided to consider, analyse and structure the design process by identifying and isolating individual design activities of the CPS system’s real-life design task (Chandrasegaran et al. 2013): the design process of the electronic system (TCU) that mainly controls the transmission and other selected tractor systems. The information, knowledge, that has arisen or has been accumulated as a result of the project implementation and the integrated documentation, was used as material for building the concept of individual components of the assistance software – including the conception of the project design activity which is the basic idea for the proposed approach (Sim and Duffy 2003; Pahl and Beitz 2007; Ullman 2003).

In their analyses, the authors of the paper used project documentation and various additional information resources created during the TCU project implementation. One of the authors was also a member of the design team.

The TCU project was developed by a team of designers – specialists and experts from various disciplines with broad professional experience. Most of these designers had relatively rich professional biographies, and they also had long experience in team project work (9 key designers from 3 companies).

The designers, team members large experience in specific design processes or some of their fragments, referred most often to their projects using terms of design activities. Design activities can be associated with various groups of issues in the design processes which have usually arisen from issues encountered during designing or testing scenarios of CPS. The main novelty in the project was the problem of specifying the scenarios for the functioning of a newly designed CPS device, both in an informal way – specifying the situations in which the structure should function, as well as formally modelling these situations to the extent that allows advanced analysis, design simulations, and problem identification and solution.

5.2. Details of initial design activity model

For modelling of the design activities, the authors of this paper used a classic approach from work (Sim and Duffy 2003). The first stage of the analysis was to identify the design activities used by individual designers in their own original version. The original version was considered, i.e. the one with which the designers started to solve the problems. The result of this stage was the separation of three classes of activities:

those that did not require any modification in the case of the currently implemented project task,

those that required relatively simple modifications that could be made at the stage of the first design iteration,

those that required far-reaching, unknown at the beginning, modification of all activity.

After analysing the process of such selection, it was noticed that the activities belonging to class (3) generally resulted from the need to design CPS elements or to solve the encountered unforeseen issues. Their current form did not allow the solution of the actual design problems. Usually, the goal of the activity was set and some new ideas (based on continuously improved input/output knowledge from the previous version of activities) appeared to solve further newly identified problems.

The designers very often began to create one or several versions of the solution to the problem, experimented, drew conclusions, and made improvements. They created new versions of those activities, and tried to apply them to a given design problem. Sometimes, extensive research material was needed.

5.3. Results of initial design activity model application

Changes made to class (3) activities required repeated design analyses to be carried out as a whole process. This, in turn, could lead to the appearance of new modifications in the types of activities (2) and (3).

During the implementation of the design process, the gradual evolution of the form of considered scenarios for the functioning of CPSs, as well as adding new scenarios to the set originally assumed, there was an additional element significantly broadening the scope of the entire design process. To a large extent, this was due to the new opportunities that arose as a result of project activities in subsequent iterations of the project (in the beginning, the semi-automatic gearbox TCU evolved into the concept of the semi-automatic/automatic gearbox TCU with on-line and remote diagnostic and monitoring possibilities).

All activities were based on the knowledge of designers, which significantly evolved in the design process. Their formal record was based on the concept of text and multimedia descriptions or on tools that automate these activities. The proposed approach assumed that the project activity may relate to a specific substantive issue. It can be modelled as a descriptive and multimedia resource (Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017) functioning at three levels of accuracy (1–3, 3 most accurate) and can be modelled as an automation tool (Liu, Zhang, and Cao et al. 2020; Amir and Givargis 2020) also at three levels of accuracy (1–3, 3 most accurate).

5.4. Concept of design activity template

Trying to build a more structured shape of the whole approach, the authors created the concept of a template related to activity (concept taken from (Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017, (Sim and Duffy 2003))), which may include both descriptive and multimedia components as well as automation components corresponding to the typology of the design activity (Sim and Duffy 2003). Additionally, designing CPS is usually multidisciplinary (in reality, in most cases these models are transdisciplinary) (Pokojski, Knap, and Trojgo 2020; Nomaguchi and Fujita 2013), leading to the need to integrate many formal models with each other.

The following two chapters present example, detailed results obtained in individual groups of issues: analysis of implemented activities, modelling of activities evolution.

6. Analysis of performed activities

6.1. Introduction to analysis

As part of the work, a number of investigations/analyses were performed, which included becoming familiar with the resources of knowledge used in the considered project task, classifying this knowledge, and tracing both the sources and processes of its evolution in relation to the solved project tasks, mainly related to work scenarios of CPS.

In the work scenarios of many designers steps typical for the case based reasoning method (CBR) (Balesdent et al. 2012; Duddeck 2008) can be found. Designers like to return to previously realized and already known/managed design processes (Pahl and Beitz 2007; Ullman 2003). They often treat them as starting material or comparative material for the currently solved task, and they often take the trouble to adapt a previous task, which seems to be easier for the designer than to formulate and realize the task anew (Arthur 2009).

Figure 1 schematically shows the evolution of activities (15) and (16) from the CPS design process. The initially accepted activity (Stage 1) concerning the selection of parameters of the gear shift control model (16A2) in the gearbox required changes because of unsatisfactory experimental results. So it was necessary to extend the cooperation of engineers with external experts. The initial deconstruction of problems into individual disciplines (Stage 2) proved ineffective, and transdisciplinary problems (Stage 3) had to be solved, especially at the interfaces between the hydraulic, electronic and mechanical disciplines. As a result, the evolution of the activity also led to the evolution of dependent activities (15) and (16) (Stage 4).

Figure 1. Development of project activity – the project activity was developed from stage 1 to stage 4 (for this to happen intermediate stage 2 and stage 3 occurred).

6.2. Modelling, evolution of example activity

The paper analyses in detail the individual activities which were extracted from the project records and the reports. The following concept of their structuring and analysing was used

1. All members of the design team were identified and their substantive profiles, professional experience, etc. were specified. This summary is presented in a simplified form in Table 1.

2. Design activities used by individual team members were identified and listed for each team member. An example of a set of activities for one designer is shown in Table 2.

3. The activities and their elements were identified. For example, one of them is shown – with its structure – in Table 3.

4. Identified version of specific components of the analysed activities. An example illustration of the versatility of the activity component is shown in Table 4.

Table 1. List of chosen team members and their characteristics

No	Team member	Area of speciality	Experience period(years)	Participation in activities (%)
1	Mechanical engineer No 2	Hydraulic systems, numerical simulations, tractor transmission and drivetrain, …	18	15
3	External mechanics and hydraulics expert	Tractor kinematics, optimization of gear change process, hydraulic systems, …	28	5
3	Electronics engineer and programmer	Electronics architecture, programmer, utility software development, …	15	10

Table 2. List of chosen activities and their characteristics – performed by one of the design team members

No	Design project activities of Mechanical engineer No 2	Characteristic of tasks in activity	(Group) Type of modifications
1	Analysis of hydraulic system supporting gear shifting	Analysis and modelling of gear shift process from hydraulic point of view	(3) complex modifications
2	Designing of gear shift process and characteristic	TCU software tests	(3) major modifications
3	Testing of gear shift process under external load	Measurement setup and tests of implemented gear shift strategy (proportional valve characteristics of disengaged and engaged gear)	(3) major modifications
4	Model and data optimization	Analysis and adjustment of control parameters in TCU	(3) complex modifications

Table 3. Analysis of hydraulic system supporting gear shifting activity and its structure

No	Activity records	Form of representation	Format
1	Documentation of previous projects of a similar type	Descriptive documentation, numerical simulation model, measurement data, experimental and numercal results, …	Files (doc, xls, pdf, …), 2D and 3D models, experimental and simulation data,
2	Technical documentation of the hydraulic system	Descriptive documentation, specifications, data sheets, …	Files (doc, pdf), 2D and 3D models, graphics, pictures, …
3	Additional requirements from other activities, e.g. design of electronic unit	Descriptive documentations, required functionalities, planned TCU scenarios, risk report, …	Files (doc, pdf, xls, vsd, .), paper reports, graphical files, pictures, video material, …
4	Experimental and numerical results and data	Experimental data, reports, video material and pictures from experimental investigation, …	Files (binary, mp4, doc, xls, raw, jpg …)

Table 4. Example metamorphoses of activity analysis of hydraulic system supporting gear shifting

Activity	Version	Characteristics of additional problems solved or discovered
Analysis of hydraulic system supporting gear shifting	Initial	At the beginning only hydraulic system, which was directly supplying hydraulic pistons of clutch of proper gears, was analysed. Experimental investigations shown improper fluctuations of pressure and the oil flow during shifting gears. This caused losing of clutches for a while after initial engagement and later second immediate engagement which caused overloading of transmission.
Analysis of whole hydraulic system of the tractor	After major modifications	To solve malfunctions of gear shifting process it was necessary to investigate whole hydraulic system of tractor including pumps, pressure relief valves, proportional valves. It was discovered poor manufacturing of hydraulic plate which caused leaks during gear shifting process. It was also necessary to introduce hydraulic accumulator to hydraulic system and adjust its volume and gas initial pressure. Although improvement in gear shift process was achieved still immediate engagement of clutch causing overloading was observed. It was discovered that, in spite of proper characteristic, control resolution of electronic components was too low causing too sharp increase in current supplying coil of proportional valves. It was necessary to include into analyses measurements of electronic system and control signals.
Analysis of all systems and software controlling gear shifting process	After further complex modification	After including into optimization parameters related to hydraulic, electric, mechanical and software parameters it was possible to determine proper control characteristics assuring proper process of gear shifting under different loads of transmission. But this also shown that was necessary to rebuild software algorithms to include possible corrections due to temperature (to compensate changes in oil viscosity) at the end of the production line during cold pickup. It was also discovered that is possible to develop automatic valve characteristic adjustment software based on a few chosen measurements at the end of production line. Due to changes in this activity it was necessary to modify other activities related to designing of TCU. For. example it was necessary to adjust measuring system to measure signals from numerous different sensor (currents, torque, hydraulic pressure, oil flow, temperature, velocities of transmission shaft, engine velocity, engine torque, engine throttle, etc.) to enable analysis of measured values at the same time.

6.3. Design problem structure and evolving set of CPS functioning scenarios

The collected and analysed documentation of the designed CPS also includes the perspective of so-called scenarios of CPS functioning. During the process of designing the TCU it is necessary to determine the set of tasks and resources required to be performed or used to provide the required functionalities. For instance, the following scenarios were identified and considered: Power Shuttle (drive control providing gear shifting under load conditions), Power Shift (semiautomatic control with the system adapted to the automatic control system), accelerating and stopping the vehicle, control of the differential lock of the rear axle, connecting/disconnecting of the front drive, connecting/disconnecting of the PTO shaft, blocking of selected gears with the Creeper gear option on, managing the Brake & Clutch function, etc. Based on the identification of tasks, it is possible to develop scenarios to be performed by CPS. Proper identification of CPS scenarios allows for finding the relationship between the system components and transmitted information, such as electric signals. Each task in the scenario can be a source of multidisciplinary problems and risk which should be covered by the design process activities – cf. Table 4.

In the discussed case of the activity presented in Figure 1, meeting the planned functionalities required iterative evolution of the activity, which was accompanied by the expansion of the area under consideration and defining key parameters in these areas due to the expected result – see Figure 2. It is basically a kind of optimization, where some target areas are defined in advance concerning the criteria (often in an implicit form) as well as applied sets of decision variables (or sets of variants).

Figure 2. Development of the activity presented in Figure 1 in iterative terms and expansion of the area under consideration and the definition of key parameters in these areas.

The relationship between criteria and decision variables (or variants) is generated by inference or search and adaptation (CBR). This aspect is shown primarily in Figure 3.

Figure 3. Multi-discipline decision making task applied to the components of the design process presented in previous figures.

In many project tasks it happens that inference leads to a problem where with a large number of solutions in the form of implicit or explicit. Arranging these solutions through inference, although possible, would usually be very laborious. This can be done by using multi-criteria optimization methods. In this case the designer models the problem, determines his preferences, and solves the task of multi-criteria optimization (Figure 3).

Returning to the example of the complete TCU design task controlling the operation of a gearbox under load, it is exactly the type of task, i.e. with many tasks, belonging to different disciplines, at different levels of modelling. Many satisfactory or unsatisfactory solutions from those calculations can be obtained. Often it is difficult for the designer to compare them. But it is possible to add a decision module to the calculation program, build optimization sub-tasks of a different range and formal representation (adjusted to the current level of solving the whole task) and, as a result, generate the most preferred solution at this stage, which can then be sent to the next module, belonging to the next activity.

What has been discussed above indicates that the original design knowledge is always the substantive one. This knowledge becomes the basis for generating specific solutions for specific situations, or it can become the basis for creating a new version of the method/tool.

7. Functionalities of assisting software concerning activities

7.1. General model of activity

As a part of the project, a model of design activity was defined: its general structure, existing forms, and individual components. A predefined typology of recognized types of activities was prepared, as well as related keyword sets. The built representation of the activity allows us to capture its development in the form of subsequent versions – cf. Figures 4 and Figure 5. This formalism is presented in a previous chapter of this work in the form of Tables 1–4 filled with content from a real-life design task.

Figure 4. Activity change modelling – an example of a field describing activity versions and key activity problems and their status.

Figure 5. Schematic representation of the activity and description of its development.

The part of the model described above focuses primarily on the aspects of storing information/knowledge, and preserving information about the relationships between individual elements. It can be implemented in the form of an object-oriented model. The authors decided to build tools that first try to capture a wide range of information which is necessary to consolidate the process of evolution of individual activities. In parallel it was decided to record, in a broader sense, contextual information on each project. Contextual information consists of all materialized knowledge resources of designers and all resources strictly related to the project. The basic structure of these resources is presented in Table 5.

Table 5. The selected basic structure of knowledge resources describing the project and activities

The model under consideration and its functioning in specific situations refers very strongly to the mechanisms observed by W. B Arthur (2009). The point here is how technology changes over time, how it evolves.

7.2. Modelling design activity development

Project implementers have also created concepts and prototype solutions in the field of model functionality, whose task is to offer the rapid and effective development of the object-oriented activity model.

During the analysis of the material documenting the sample task, attention was drawn to the large number of activities that already existed at the time of project implementation but required modifications made by the designers. Such modifications can be performed in a basic way by editing the object model and attaching it to the rest of the model.

The authors drew attention to the fact that system users – CPS designers, in this type of circumstances, usually work in two areas: 1) conducting problem-oriented, filtered analysis of the content of previously created data structures and knowledge, 2) creating and analysing hypothetical extensions of already created data structures and knowledge. Users are usually interested in more effective solutions than manual analysis or extension of the existing object-oriented model (Carreira, Amaral, and Vangheluwe 2020; Biffl, Luder, and Gerhard 2017).

7.3. Problem-oriented, filtered analysis

An important element of the newly modelled concept, of the assisting system, are mechanisms that allow for quick filtration of information and quick compilation of information depending on the contexts. It is equally important to search for the right form of a given activity, within a predefined set of forms.

7.3.1 Tools for fast visualization of activities and their contexts

The project assumes that work with the system should take place with a high level of search automation, appropriate for the problem being solved. In the absence of an existing, relevant instance of activity, helpful contextual information should be generated quickly, visualizing available, related instances of activity, their sources, and examples of use in specific, previous projects.

7.3.2 Pre-configured activity templates

If a designer decides to create a new activity model, they are offered the option of using pre-configured activity templates – cf. Figure 6. For instance (Arthur 2009): – activity with substantial parallel extension, activity with hierarchical extension, etc.

Figure 6. Variants of design activity evolution modelling.

7.3.3 Multi-stage model of project activity development in connection with contextual information

The activities, examples of which are presented in the previous part, show how the key information for modifying them was captured in the computer system. The tests of this concept indicated the need to take into account not only changes in the representation of the activity itself, but also observations of a relatively quite wide area of so-called contextual information on each of the modified activities. This was done by building a computer environment-cf. Figure 7. Its assumptions are presented in Table 5 and examples of use are shown in Figures 6 and 7.

Figure 7. Example of representation of the activity and description of its development with use of the discussed supporting tool.

There is a wide comprehensive description of the problem and a large number of additional parameters and characteristics which were taken into account, stored and classified. This information is quite important because it may play an important role in the evolution model of a given analysed activity. Some of the changes result from the uncertainty of the descriptions used. The authors have introduced a system of additional information classification providing for: desired state of information, acceptable state, state initiating specific, necessary actions. The necessary actions can take the form of an articulated description of the necessary actions or of a formal algorithm corresponding to these actions (being the first phase of its automation), or the automation itself. Figure 8 shows selected elements, taken from those listed in table 5, which have been reclassified in the description of the new activity (activity 16 from Figure 1 in stage 4) in the sample processes of their modification (possibility to automate the selection of control characteristics at the end of the production line).

Figure 8. Example of a representation of the problem related to the activity and description of its potential future evolution with the use of the discussed supporting tool.

Further actions have shown that most modifications of design activities are not limited to the components of the activity itself. Additional contexts are also important or even very important. To work with such a wide stream of information completes the picture of the perceived complexity in the process of activity modification. It shows the area of analysis and design decisions taken into account.

When analysing a few subsequent, step-by-step modifications of a specific activity the evolution of the used design environment seen from the current perspective of the knowledge providers can be observed. Several subsequent steps of the activity evolution generate, in many cases, a certain subprocess of a holistic (e.g. substantial issues) and intentional (e.g. planned/expected improvements) nature.

The implementation of the software model activity development process, combined with the above-mentioned automation of additional information analysis processes, may lead to the gradual automation of the whole subprocess. This evolution is schematically presented in Figure. 9.

Figure 9. Evolution of the gear shifting process together with holistic and intentional sub-processes.

The evolution of even the simplest activity may not only lead to modification of the activity itself, but may also affect other activities and may be a source of new ones. Additionally, the evolution of an activity which results in potential additional benefits leads to taking risks and implementing another modification or planning it for the future depending on resources. Of course, each activity already realized or potentially possible to realize has its own financial conditions. They result not only from the cost of realization and the expected frequency of future use of the new software, but also from the knowledge necessary to realize the activity – see the diagram of such a procedure presented in Figure 10.

Figure 10. Selected conditions influencing the possibilities of evolution and improvement of the design process based on the example of the gear shifting process.

The proposed approach implies that the modelled design processes do not have advanced formal models of high quality. But they must allow easy access to the knowledge arising from continuous change and evolution as the design project matures. Thus, designers make numerous partial attempts to formalize them in a limited scope and carry out activities which are a rational monitoring and management of these attempts and related information resources. However, the final goal of these activities is to make the construction of advanced formal models possible that allow for the “better expressing” of expert knowledge.

7.3.4 Final comments

All solutions developed to improve the process of creating advanced activity models depend very much on the data sets that are used at the time of testing.

The authors in their achievements relied on the documentation of an example project task. The process of testing the concept consisted basically in analysing different sets and subsets of information/knowledge elements and the relationships between them. At that time this process was largely manual.

8. Conclusions

The authors, after completing the analyses presented in the work, attempted to create tools that allowed them to refer to specific functionalities, i.e. their characteristics and resources, versions, or applications.

The presented work was created as an analysis of materials and retrospective threads related to the previously realized project. The threads considered in the analysis mainly concerned 2 aspects: the observed degree of substantive correctness of the project activities and the intentionality of those activities which aim at selected, strictly defined directions of the development of the entire project. These activities were accompanied by reflection, mainly substantive.

The conclusion of the above-mentioned activities was to formulate conclusions concerning the directions of improvement of the realized project and to formulate conclusions concerning the methods of computer development to support its realization process. While realizing it, it turned out that following this direction resulted in obtaining effects very close to many works of other authors mentioned in the literature review for this paper. The developed concepts were characterized by the very high complexity of formal models used and significant deficiencies in the data and characteristics. Generally, this led to the realization of probably not always necessary and sensible actions, which resulted mainly from the adopted, very broad and complex initial structural models. These approaches were very labour-intensive and thus too expensive.

The conclusion at this stage was to focus on the activities discussed in the authors’ work (Ferguson, Kasprzak, and Lewis 2009) concerning the process of the modelling of one project activity, or a set of related project activities, treated as a key resource of substantive project knowledge. There were both flashbacks (chapters 4 and 5 of this paper) and attempts to create relatively simple and flexible tool solutions (chapter 6) of project activity modelling, which is constantly evolving together with growing expectations for new functionalities of CPS systems. These activities were accompanied by attempts to model various conclusions and verify certain hypotheses. The attempts were not always successful. This paper presents only these achievements with an acceptable level of effectiveness.

The authors are planning to prepare and implement several design tasks which have important industrial references and may become examples of practical use of the procedure proposed in this paper.

Then the newly created functionalities will be tested on real-life examples of other CPS.

Disclosure statement

No potential conflict of interest was reported by the author(s).