Method and software tool for formulating executable specifications in the context of system development or validation of complex functional systems

Abstract

The invention relates to a computer-implemented method for formulating executable specifications in the context of system development and / or system validation of a functional system for a target device, in particular for a motor vehicle, comprising the following steps: - providing at least one model view of a functional system comprising one or more functions (F, F1, F2, F3, F4) for controlling or regulating a target device; - providing a selection interface designed for selecting and changing system parts by a user in the provided first model view; - transforming and displaying the selected and / or changed system parts in the first model view in at least one corresponding further model view for the user; - providing a specification and release interface designed for selecting and / or checking and / or further adapting the system parts displayed in the at least one corresponding further model view or changing and designed for releasing the changes to the system made by the user in the first model view and / or in the at least one corresponding further model view; - automatically adopting the released changes to the system into the at least one corresponding further model view.

Description

Technical Field

[0001] This invention relates to a computer-implemented method for developing and / or verifying executable specifications for functional systems of target devices, particularly motor vehicles. The invention also relates to a corresponding software tool and a control unit configured to implement the described method. Background Technology

[0002] Model-Based Systems Engineering (MBSE), such as from... Pohl, Klaus , Manfred Broy , Heinrich Daembkes and Harald Hönninger “ Advanced Model-Based Engineering of Embedded Systems – Extensions of the SPES 2020 Methodology Springer, a well-known modeling platform since mid-2016, is increasingly prevalent in the development of complex functional systems, particularly those implementing innovative functions in automotive applications for automated driving or to improve vehicle energy efficiency. Software tools, such as those using graphical modeling languages ​​like SysML or OMG SysML (OMG Systems Modeling Language, registered trademark, ObjectManagement Group, Inc.), or E / E architecture development tools (E / E architecture here stands for "Electrical-Electronic Architecture," which specifically describes the electrical and electronic components present in a vehicle and how these components interact with each other), such as PREEvision (registered trademark), are suitable for describing the logical-functional or causal relationships of even complex systems in the form of a functional or logical model view at an early stage of system development.

[0003] This type of existing known approach allows for a structured description of a system in the form of functionality and its dependencies. The latter is typically specified in the form of interface descriptions. This structured description of a functional system is also referred to herein as a static system description. Here, a static model view, such as a static functional system description, is provided to users or system developers. This includes: one or more cause-effect chains that describe the causal relationships between the effects of physical functionality in the target device and target parameters; or a functional architecture in which the functional common parts of different cause-effect chains are aggregated and arranged hierarchically according to functional dependencies.

[0004] In addition to structured descriptions, behavioral descriptions of complex functional systems are used, typically limited to causal relationships, time-sensitive sequences, or state-oriented systems described using state machines. In known methods, the description of the dynamic system behavior of time-continuously regulated or controlled systems is decoupled from the structured descriptions performed using specialized software simulation tools such as MATLAB / Simulink (trademarked).

[0005] Here, the coupling between the structured static model view and the dynamic behavior description is delegated to the user. Existing solutions are unidirectional and, if any, only have limited semantic coupling between modeling elements with different model views. This is due to the fact well-known to those skilled in the art: just as SysML tools for dynamic behavior description are less suitable, software tools for dynamic behavior description do not support all the necessary static model views. For example, common artifacts to be modeled, such as entire use cases, individual features and functions and their interfaces and variations, causal chains in static or dynamic descriptions, or E / E structures, cannot be fully supported in the early stages of system development by all three different software tools—first, the appropriate requirements tooling; second, SysML; and third, MATLAB / Simulink. Therefore, it is also impossible to use a single tool to describe all the necessary models and views in order to ensure, for example, consistency between different model views. Summary of the Invention

[0006] According to the present invention, a computer-implemented method for developing executable specifications for system development and / or system verification of a functional system, as described in claim 1, is provided, along with a control unit configured to implement the method, as described in the co-claims, a corresponding software tool (computer program), and a machine-readable storage medium, as described in the co-claims, on which the software tool is stored. Other embodiments are described in the dependent claims. All further features and effects mentioned in the claims and specification with respect to the method also apply to the software tool and the control unit, and vice versa.

[0007] According to the first aspect, a computer-implemented method is provided for developing executable specifications in a software-tool-assisted manner for system development and / or system verification of functional systems that are typically arbitrarily complex, designed to achieve various functionalities for the control and / or regulation of target equipment, particularly motor vehicles. Here, "software-tool-assisted manner" refers to the novel, entirely specialized software tool described herein in the claims or further hereinafter, specifically designed for implementing this method, which, for implementing the method, can be installed and run, for example, in a computer, control unit, or other data processing equipment used for system development and / or verification.

[0008] Specifications developed using this method can be, for example, modifications or alterations made to the system by users such as system developers or simulation experts. These specifications, in particular, can produce specific technical effects when the system is implemented in a suitable control unit of the target device, such as measuring, displaying, and / or changing current vehicle speed, engine speed, temperature, or any other physical operating parameters of the vehicle or other target device. Here, the functional system includes one or more functions for controlling or regulating the target device. For example, the functional system can be a driver assistance system, such as Lane Keeping Support (LKS) or Adaptive Cruise Control (ACC), which may include functions such as receiving and / or determining the current motion parameters of the vehicle and / or other vehicles traveling in front, behind, or overtaking, and accordingly determining new motion parameters adapted using vehicle control that causes corresponding changes; or the functional system can be an energy management system, and so on.

[0009] Here, the "executability" of this specification means that, using this method, it can be ensured that user-made changes resulting from the specification are tracked to guarantee their consistency with the overall system and, for example, with pre-determined technical requirements for the executability of the specification on the target device. To this end, this method includes the following steps:

[0010] - Provide at least one model view of the functional system, particularly a static functional system description and / or other structural (or also static) description and / or dynamic behavioral description (simulation model) in the form of functionality and its dependencies. Here, a model view refers to a model-based system description in a representation or language that is at least partially graphical and understandable to a correspondingly trained user. To provide the corresponding model view, software tools suitable for system development or simulation, such as SysML, Preevision, or MATLAB (corresponding registered trademarks), can be used, for example, as mentioned at the beginning or other well-known software tools that are accessible, such as those described herein.

[0011] - Provide a selection interface designed for users to select and / or change system parts in the provided first model view. These system parts may include, for example, various functions with related interfaces or other modeling elements of the functional system.

[0012] - The system parts selected and / or modified in the first model view, in particular the changes made and / or their effects and / or the changes in dependencies in the rest of the system, will be displayed as at least one corresponding additional model view for the user;

[0013] - Provide a specification and release interface that is designed to select and / or inspect and / or further adapt changes displayed in at least one corresponding additional model view and is designed to be released by the user to changes to the system made in the first model view and / or at least one corresponding additional model view.

[0014] - Automatically apply the published changes to the system to at least one corresponding additional model view and complete the changes to the system.

[0015] In this document, the term "user" can include not only an individual but also multiple different individuals, such as: a system developer who participates in the static functional system description; a simulation expert commissioned to perform dynamic behavior description; and / or a group of experts from different technical fields responsible for the different vehicle domains affected by the functional system, such as engine control, driver assistance systems, energy supply, air conditioning systems, etc. In this method, individual users or correspondingly different users can not only make changes in a single model view but also, when necessary, in multiple different model views, which serve as either the first model view mentioned above or as the corresponding additional model views mentioned elsewhere.

[0016] The idea behind this method is to achieve semantic coupling in the aforementioned transformation and display steps—a process supported by tools—between changes made by the user in one of the available model views to the same system in a corresponding other model view, and the user / user's tracking and assurance of the changes and / or evaluation of these changes before their final adoption in the system via the specification and release interface. In this paper, the semantic coupling of the corresponding modified model elements of the system between different model views is understood in particular as content-related, logical, and / or functional coupling of these model elements, which can, ideally, fully reflect the actual technical effects of the corresponding changes to the system in the corresponding other model view. This ensures consistent tracking and assurance of consistency between changes brought about by the specification and the overall system and the predetermined technical requirements for the system's executability on the target device. Semantic coupling between static model views and dynamic behavioral descriptions can be achieved in particular here.

[0017] By coupling this semantic and software-tool-assisted approach not only in the early stages of system development (the so-called upper left part of the known V-model) but also in the static and dynamic model views concerning system verification, that is, towards the upper right part of the V-model, the shortcomings described at the beginning of the known solutions to date can be overcome. The so-called V-model is an intuitive graphical representation of the sequential development and verification phases of a system or software over time, arranged in a "V" shape, where each development phase on the left branch of the V is opposite a corresponding testing phase on the right branch of the V. Here, starting from the upper left part of the "V" and moving downwards to its apex, the sequentially sequential development phases are arranged, for example, from requirements analysis (requirements engineering) through the development of system architecture and increasingly detailed functional and technical specifications culminating in the software and hardware implementation foundation at the apex of the V. These development phases are then verified on the right side.

[0018] Therefore, this invention enables the realization of an executable specification (simulation) of a functional system, the consistency of which with the static or dynamic description can be guaranteed through software-tool-assisted coupling of relevant modeling artifacts, such as causal chains or individual functions or their interfaces. The methods described herein intentionally include a user who can utilize their expertise to perform rationality checks, verifications, and then release modifications and their dependencies. Here, the specification and release interface particularly support the individual release of corresponding changes, the release of a predetermined set of artifacts with changes, and / or the total release of all changes.

[0019] In this method, in addition to the functions selected and / or modified via the selection interface, the defined dependencies of these functions, especially their interfaces and descriptions, can also be transferred / transformed into corresponding additional model views, where the defined dependencies of these functions, especially their interfaces and descriptions, are displayed to the user. Here, these dependencies can be displayed / presented to the user in particular clearly, for example, by being sorted according to relationship type, according to original and / or target artifacts, etc.

[0020] In particular, the first model view and at least one corresponding additional model view may include two or more of the following model views of the functional system:

[0021] - A static functional system description, which in particular includes at least one functional causal chain that describes the causal relationship between the effects of physical functionality in the target device and the target parameters;

[0022] - Dynamic behavior description, which in particular includes simulations of the system's dynamic behavior generated using simulation software;

[0023] - Functional architecture, in which the common parts of different causal chains are aggregated and arranged hierarchically according to functional subordination;

[0024] - Technical architecture, in which the common parts of different causal chains are aggregated and arranged hierarchically according to technical subordination;

[0025] - Requirements engineering, which specifically describes the technical requirements for each part of the system.

[0026] Here, for example, the first model view can be a static functional system description and one of the corresponding other model views can be a dynamic behavioral description, or vice versa. Here, the method steps described in the general description above can be implemented in particular such that:

[0027] - Users select and / or change the entire functional causal chain or one or more parts of that causal chain in its static or dynamic description via a selection interface;

[0028] - In the transformation step, starting from the static description, for each part of the selected and / or modified part of the causal chain, the functional body in the dynamic behavioral description is automatically generated and / or selected from the existing functional body inventory and displayed to the user using simulation software.

[0029] - The specification and release interface are also designed to allow changes to be made in other model views, such as in the dynamic behavior description, and to feed these changes back to the first model view or usually to at least one structured model view, such as to the static functional system description and / or to the functional architecture, in order to check for any inconsistencies with the rest of the system.

[0030] Here, changes can be, for example, alterations, additions, or deletions of functions or interfaces in a functional causal chain, and are also displayed to the user as “changes,” “additions,” or “deletions” in the first model view and in the corresponding additional model views.

[0031] In this regard, the specification and release interface can also be designed to provide users with a choice among one or more of the following options for the system section to which feedback is to be provided:

[0032] - All functions and interfaces;

[0033] - All functions and related interfaces up to the level of detail that the user wishes to define through the specification and release interface, or all major functions with these related interfaces;

[0034] - The features and interfaces that users choose through the specification and release interface.

[0035] Here, these primary functions, for example, represent the scope of functions required for implementing features or use cases and describe their logical or physical relationships, in a manner known per se. In order to make the aforementioned choices or satisfy the corresponding requests of the underlying software tools or control units, the user can or must, for example, identify in one of the model views whether these functions or interfaces are primary or secondary functions of the system. Here, secondary functions can be distinguished from primary functions, for example, in a manner known per se, as follows:

[0036] The functional considerations of causal chains and functional architecture typically mandate the inclusion of primary functions. However, if iterative development is being performed, such as as described in the SPES modeling platform mentioned at the beginning, it may also be meaningful to supplement the functional descriptions of secondary functions. Here, different solution possibilities often exist, which can be understood and evaluated from the user's perspective using functional considerations. Importantly, these functions are identified as "secondary" because behind the consideration of specific secondary functions, correspondingly trained design decision-makers with the necessary technical knowledge are at the technical architecture level, such as the need for high-temperature cooling circuits when using combustion engines or ICE (internal combustion engines). Furthermore, if a safety concept is used, which decomposes safety objectives through redundancy, redundant functions / functionalities are also required. These redundant functions / functionalities must first be distributed across suitable components, which can or must be identified and considered as secondary functions. Changes in design decisions at the technical level can affect these secondary functions. Correspondingly, these dependencies between technical and functional perspectives are documented.

[0037] Therefore, in these and all other designs of this method, the checks in the specification and release interface may include a user's request to contact an organizational unit trained to the appropriate check or release location. This can be supported, in particular, by storing the corresponding trained user and, if necessary, at least one representative's telephone number and / or contact address in a software tool or control unit of the type described herein, or by implementing an automated process for querying and providing the user's appropriate contact data.

[0038] The distinction or identification of primary or secondary functions is primarily based on the fact that functions in a real system always require an execution platform on which they run. This platform uses suitable technologies, such as microcontrollers, memory modules, power semiconductors, but also CAN buses, Ethernet, and so on. This can be seen as the practical task of the technology—representing the execution platform of the function. Here, a technology is usually never perfect (not high-performance, reliable, safe, etc.), and therefore must always be checked to ensure compliance with predetermined technical requirements (e.g., functional safety) and adapted where necessary. An example of a secondary function is a thermal system for component cooling. This thermal system becomes necessary, for example, to prevent overheating of components that inadvertently convert energy into heat due to inefficiency.

[0039] In a specific design scenario, the approach described herein includes: transforming into a functional architecture; and / or implementing in the specification and release interface the inspection of changes to the functionally identical parts of different causal chains and their matching. Here, in the absence of a matching, if necessary, this can be communicated to the user by automatically requesting further changes to the functions involved—that is, by automatically requesting functional variants that create these changes—using which the matching can be reconstructed. In particular, the user can also be provided with automatic suggestions of functional variants for achieving the matching, in the form of possible change options. For example, in a driver assistance system, the functionally identical parts of two different causal chains can be common functions, such as "detecting vehicles ahead, behind, and overtaking," where one causal chain implements Adaptive Cruise Control (ACC) and the other implements Lane Keeping Support (LKS).

[0040] In another aspect, a control unit is provided, comprising a processor configured to implement methods of the type set forth herein. This control unit may, for example, be part of a computer or computer network suitable for system development or verification.

[0041] According to another aspect, a software tool (computer program) as mentioned above in the description of the method is provided, the software tool including instructions that, when executed in a control unit or other data processing device of the type set forth herein, cause the control unit or other data processing device to perform the method of the type set forth herein.

[0042] On the other hand, a machine-readable storage medium is provided on which such software tools (computer programs) are stored.

[0043] Therefore, using the approach described in this paper, the semantic and software-tool-assisted coupling between the cause-effect chain (CEC) and dynamic behavioral description (DVB) in a static functional system description can be determined, in particular. To this end, unlike the prior art described at the beginning for system development and / or system verification, this method includes a bidirectional, automated transformation of the modeling artifact between the CEC and DVB, which may, for example, have the following steps:

[0044] - Use the entire causal chain or a selected portion of the causal chain;

[0045] - Provide / display an adaptable representation to the user: what changes were made in the corresponding additional model view and what impact this has on its own model view;

[0046] - Here, artifacts such as functions or interfaces are marked as added, changed, or deleted;

[0047] - Changes are presented when the work-in-process is altered;

[0048] - Before the changes are finally adopted, users can evaluate them using the specification and release interface;

[0049] - Users must publish their adoption of the modified artifacts separately according to CEC or DVB;

[0050] - Supports individual releases, artifact set releases, and total releases of all changes;

[0051] - Only published changes are ultimately adopted in the corresponding additional model views.

[0052] Here, in addition to the impact of changes in CEC or DVB, it is also important to indicate to users, in particular, the dependencies of the modified artifacts on other model views used in model-based approaches for system development, such as the MBSE (Model-Based Systems Engineering) mentioned at the beginning. This could be, for example:

[0053] - Functional architecture;

[0054] - Requirements engineering; and / or

[0055] - Technical architecture.

[0056] In this case, the available information and practices are similar to those described above regarding the CEC and DVB coupling. Attached Figure Description

[0057] The above aspects, their implementation methods, and specific design schemes are then described in more detail with reference to the examples presented in the accompanying drawings. Wherein:

[0058] Figure 1 A flowchart illustrating an example of a method for developing and / or validating executable specifications for a functional system, here a driver assistance system for a motor vehicle, of the type described herein;

[0059] Figure 2a A schematic example of a static functional system description with three distinct causal chains is shown, which is used as a basis for... Figure 1 The first model view in the method;

[0060] Figure 2b It shows the relationship with Figure 2a A schematic example of the corresponding functional architecture;

[0061] Figure 3a Another illustrative example of a static functional system description for representing an ACC causal chain is shown, which is used as a representation of the ACC causal chain. Figure 1 The first model view in the method;

[0062] Figure 3b It shows the development of information about Figure 3a A simulation framework that provides an illustrative representation of the dynamic behaviors of user-selected functionalities.

[0063] Figure 3c This illustrates a detailed simulation model, which is designed by the user according to... Figure 3b Developed within the simulation framework provided; and

[0064] Figure 3d As shown in Figure 3a As in the middle, it has the following: Figure 1 The method of feedback and display of changes to the system to the user is a static functional system description. Detailed Implementation

[0065] In comparison, all embodiments, variations, and design features of the method according to the first aspect above, as well as the corresponding software tools, control units, and machine-readable storage media according to the other aspects above, as mentioned in the above specification and in the following claims, can be implemented... Figures 1 to 3d The examples shown are implemented individually or in combinations mentioned above. Therefore, these implementations, variations, and specific design features will not all be repeated hereafter. The same applies correspondingly to the aspects already described above regarding… Figures 1 to 3d The terminology definitions and effects of the various features shown are illustrated in the text.

[0066] Figure 1 A flowchart illustrates a method, of the type described herein, for developing and / or validating executable specifications for a functional system of a target device, in this case, a driver assistance system for a motor vehicle. Some implementations of this method and its possible specific embodiments are primarily referenced first and foremost in… Figure 2a and Figure 2b The static model views M1 and M2 of the driver assistance system shown in the figure are used to describe the example, and then in another ACC regulator development example, based on Figures 3a to 3d This will be further clarified.

[0067] In the first step S1, the user is provided with a static functional system description M1. Figure 2aThe simplified and schematic first model view of the system is presented below, which in this example includes three distinct causal chains W1, W2, and W3. Here, the first causal chain W1 describes a simple example of Adaptive Cruise Control (ACC), the second causal chain W2 describes a simple example of Lateral Lane Centering, and the third causal chain W3 describes a simple example of Highway Pilot. Figure 2b The system is shown in relation to Figure 2a The corresponding functional architecture M2 is another static model view that complements the form, which will be discussed in more detail below.

[0068] In automotive applications, new innovative features for automated driving or improved vehicle energy efficiency are often not limited to a single vehicle domain, but rather extend across multiple vehicle domains as complex causal chains. These complex causal chains can be described, for example, using activity graphs in the form of sequences of activities F and their dependencies via interface C, as in... Figure 2a As schematically depicted in the diagrams using various blocks and connecting lines, these activities are also referred to herein as functions or functionalities. This causal representation of static relations, aided by system development tools such as SysML (trademarked), mentioned above, can be extended to dynamic behavior descriptions M3 (not shown) using specialized simulation tools such as MATLAB / Simulink (trademarked), also mentioned above. Figure 3b and 3c (The model elements are schematically outlined in the diagram), and this dynamic behavior description represents another model view in the aforementioned sense.

[0069] Now, according to Figure 1 The method enables the semantic and bidirectional coupling of the individual model elements to be specified in these static and dynamic model views M1, M2, and M3 to the common system during the development and / or verification of the common system, supported by novel software tools of the types described herein. Here, the unified term "user" refers to all the different individuals subsequently mentioned who participate in the system development or verification within the framework of this method, such as: system developers who participate in the static functional system description M1; simulation experts entrusted with the dynamic behavioral description M3; and / or expert groups from different technical fields responsible for the different vehicle domains affected by the system, such as engine control or energy supply.

[0070] In step S2, following step S1 above, a selection interface is provided to the user. This selection interface is designed for the user to select from the first model view, such as... Figure 2aThe static functional system description M1 shown in the figure allows you to select and / or change parts of the system. Because modeling the entire causal chain is not always reasonable due to complexity or cost, the user can select not only the entire causal chain W1, W2, or W3, but also only a portion of the causal chain.

[0071] In the next step S3, the system portion selected or modified by the user in the first model view in step S2 is automatically transformed into a dynamic behavior description M3 and displayed to the user. For this purpose, in this example, a function body is automatically created in MATLAB / Simulink for the selected portion. Furthermore, the dependencies of the selected / modified system portion defined in the first model view, such as interface C and its description, are transferred (see [link to relevant documentation]). Figure 3a These interfaces can be described in a manner known to themselves through suitable typical specifications / attributes, such as name, logical physical quantity, value range, resolution, quantization, latency requirements, and / or other specifications regarding "Quality of Service," etc.

[0072] For cases where a simulation model already exists for the selected portion of the causal chain, the software tool implementing this method provides the user with assistance regarding which functions already have counterparts in the simulation model. Furthermore, it indicates to the user any changed, added, or removed functions in the functional causal chain W1, W2, or W3, and displays the type of change. For example, it shows whether the interface has been modified and where those modifications are located.

[0073] The removed functionality is simply characterized as "deleted" in steps S2 and S3, and the user can decide how to handle the situation in the subsequent process (step S4). If necessary, the user can indicate that the functionality is still needed, and seek clarification, for example, by involving other experts / users.

[0074] In the next step S4, a specification and release interface is provided to the user, which allows the user to select and / or inspect and / or further adapt to the dynamic model view, as well as other model views (such as according to...) if necessary. Figure 2bThe user can then view and publish the elements and changes shown in the functional architecture M2. In this example, the functional developer or simulation expert can now develop, simulate, and evaluate the dynamic behavior description M3, typically a DAE model (Differential Algebraic Equation), based on the aforementioned functional body. To this end, the user uses the interfaces already defined in the static first model view and transferred to the dynamic model view in step S2, and supplements or modifies these interfaces as needed. Similarly, the function F can be extended, added, or refined according to the hierarchical decomposition of the functional architecture M2.

[0075] Here, the specification and publishing interface are also designed in this example to automatically feed back knowledge of the dynamic behavior description M3 to, for example, according to... Figure 2a The static functional system description M1 and / or automatic feedback to according to Figure 2b The functional architecture M2 is designed to ensure that changes made in the dynamic model view are compatible with the remaining functionality of the involved causal chain (in the case of partial causal chain simulation) or with the functionality of the rest of the system or vehicle (e.g., with other causal chains), meaning there are no contradictions or conflicts. Therefore, in this example, these changes are fed back into the functional architecture M2 so that the user can check for any contradictions.

[0076] Here, feature developers or simulation experts can specifically choose which parts of the simulation model should be fed back. The specification and release interface, for example, supports the following selection possibilities for feature feedback to static model views M1 and / or M2:

[0077] - All functions and interfaces are fed back, for example, into the functional architecture M2;

[0078] - All functions and all related interfaces, or all major functions with these related interfaces, are fed back up to the level of detail specified by the user;

[0079] - The user's selected features and interfaces are fed back.

[0080] If the simulation expert has already made this choice in the specification and release interface, taking into account primary and secondary functions (see details on the distinction between primary and secondary functions explained more above), then the software tool performs a comparison between the function body, including its interface, in MATLAB / Simulink and the function in the causal chain description in SysML, following the current example method. Here, for example, it can be automatically checked whether a function has been added or removed. It can also be automatically checked whether a function has been changed, that is, whether there is a modified function description or interface.

[0081] In this case, the distinction between the following two situations can be achieved using this method or corresponding software tools;

[0082] - A complete causal chain, for example, from Figure 2a In this case, W1, W2, or W3 are fed back in a closed loop. No further examination of this causal chain is required.

[0083] - Parts of the causal chain are fed back. In this case, the SysML side examines the dependencies of the changed, added, or removed functionality on the rest of the causal chain and presents these dependencies to the user for evaluation, i.e., in the case of displaying an evaluation request in the specification and release interface. Here, the user can confirm / release each dependency individually or by means of a collective release, or can reflect potential conflicts back to the dynamic behavior description. Only published changes are adopted.

[0084] In both cases, the SysML side can also automatically check formal modeling guidelines, naming conventions, etc. Appropriate display or evaluation requests within the specification and release interface can draw users' attention to potential convention violations, etc.

[0085] Here, the modified function can have dependencies beyond just those within a causal chain. Therefore, in Figure 2b The functional architecture M2 presented as an example can be another basic model view at the functional, static, or structural level. The purpose of this static model view is particularly to identify the common elements between the causal chain and the possibility of developing functional variant concepts:

[0086] Figure 2a The three different causal chains W1, W2, and W3 mentioned above are shown, and Figure 2b The relevant functional architecture is illustrated. This architecture aggregates functionally similar parts and arranges these parts hierarchically according to their functional dependencies. In this example, causal chains W1-W3 have a functionally similar part G, which corresponds to a common function in the corresponding functional architecture, such as "detecting vehicles ahead, behind, and overtaking." If this common function is changed in one of these causal chains W1, W2, or W3 during simulation, the following checks can also be performed for the other two causal chains in the current method example: whether the changed function can be used, or whether it is necessary to use functional variations for all three causal chains W1, W2, and W3. These dependencies can be specified to the user in the specification and release interface. If necessary, the user can then find common solutions for different causal chains W1, W2, and W3 through manageable changes at the function level.

[0087] However, in this approach, dependencies between changes made and the functional architecture M2 can be implemented not only in a similar manner but also dependencies between changes made and adjacent development steps, such as functional requirements or technical architecture. All modeled dependencies can be displayed to the user using corresponding evaluations and / or adaptation requests within the specification and release interface.

[0088] To clearly present what may be a larger number of dependencies, these dependencies can be grouped and presented, for example, according to the type of relationship, according to the original and / or target artifacts, etc.

[0089] Since assessing potential consequences often requires multiple experts from different technical fields, the corresponding organizational units and their contact data can be stored in the current software tools to facilitate rapid communication. Corresponding requests can be implemented within the specification and release interface, preventing changes from being released without, for example, completing specific types of modifications.

[0090] In the following text, according to Figure 1 The method described herein can be further referenced. Figures 3a-3d These figures illustrate how, when using this method or software tool, the selected elements of the causal chain W4 for the ACC regulator can be developed or further specified using a simulation model, namely, a dynamic behavior description M3. For comparison, see [reference]. Figure 2a and 2b The described method steps S1-S4 are also applicable to... Figures 3a-3d The examples shown are therefore not repeated in detail here.

[0091] Similar to the previous example, the knowledge gained in the dynamic model view during development will ultimately be fed back into the original causal chain W4, that is, fed back into the chain according to... Figure 3a or Figure 3d The static functional description M1 is used to inform the user of the changes made. Here, according to... Figure 1 The following system development steps are supported by the method or corresponding software tools running on the computer for the respective "user":

[0092] 1. The system architecture describes the functional relationships of the feature ACC in the form of a causal chain W4, such as in Figure 3a As simplified in the presentation. In accordance with... Figure 1 In step S1 of the method described above, the first model view of the feature or system obtained is provided to other users in the form of a static functional system description M1.

[0093] 2. The function or feature F1 within this feature, in this example, is the function "Calculate ACC trajectory". The developer selects this feature F1 in the first model view via the selection interface provided in the above method step S2.

[0094] Now, in the subsequent method step S3, the data is automatically generated using software tools. Figure 3b The simulation framework is presented schematically for developing a dynamic behavioral description M3 of the functional F1. Here, all information is automatically adopted, and this information is contained within... Figure 3a In the causal chain description of functional F1 in the first model view, such as

[0095] - Interfaces C, C1... with their signatures;

[0096] - Qualitative requirements for interfaces C, C1..., such as quantitative specifications for low, medium or high data volumes, clock timing requirements and latency requirements; specifications regarding functional safety, etc.

[0097] - Provide a more detailed description of the functional attributes F, F1..., such as descriptions of functional safety, operating system, computing power, memory, etc.;

[0098] - Textual descriptions of functional F, F1...;

[0099] - References to the requirements that should implement this functionality F, F1...

[0100] 3. For example Figure 3c As shown, the functional developer can now develop a refined simulation model within the provided simulation framework, which defines the dynamic behavior of the functional F1. To this end, the functional developer, for example, introduces other simulation elements that describe this behavior and associate it with available input and output parameters. The developer describes these parameters and, based on the simulation, defines the range of values, resolution, units, time requirements, etc., for these variables. When needed, the developer can introduce other parameters, such as, in this example, the division of the input parameter C1 of the "object data" into acceleration a, velocity v, and the distance gap from the vehicle ahead.

[0101] 4. When needed, the developers here not only refine functionalities already included in the causal chain W4, such as F1, but also introduce new functionalities, such as... Figure 3d The newly embedded function F3, "Prepare display data for ACC," will also introduce new dependencies. Thus, a new interface C3 will be introduced for "displaying data."

[0102] 5. If the dynamic behavior description M3 is sufficiently complete, the feature developer can have their changes reflected back into the static functional model view M1 using tool-assisted methods, that is, through the specifications and release interface provided in step S4 above. Figure 3d As illustrated. In the first step, the changes made are only identified in the first functional model view M1 and must first be published via the specification and release interface for final adoption in the feature / system ACC regulator.

[0103] 6. Here, in this approach, the user, and thus the system architect, obtains an adaptable representation: what changes were made in the corresponding additional model view and what impact this has on their own model view. In this example, this is in Figure 3d This is illustrated in the static functional model view M1:

[0104] - For example, mark artifacts such as function F, F1... or interface C, C1... as added, changed or deleted;

[0105] - Changes are presented when the work-in-process is altered;

[0106] - In this way, Figure 3d In this context, the selected and / or modified original functionality F1 is identified, as is the modified input parameter C1. Here, the refined interface specification is presented to the user through the explanation box E1;

[0107] - In addition, by following Figure 3d The display indicates to the user that this interface change also affects functionality F2, which must provide this information; here is the changed input parameter C1. This allows the system architect to coordinate these changes with the person in charge of functionality F2 before releasing them.

[0108] Functionality F3 and its output parameter C3 are characterized as new. Here, the system architect must evaluate its necessity and, if necessary, check whether a similar functionality already exists and whether the same part G can be used. In any case, the impact on the next functionality F4 in the causal chain W4 should be evaluated, and these impacts should be coordinated with the functional owner of F4 if necessary.

[0109] 7. This enables system architects to evaluate identified changes, and, if necessary, to evaluate them together with the functional owners (F1, F2, F3, and F4) involved. System architects can now decide which changes to release or, if necessary, consult with functional developers and consciously avoid adopting changes.

[0110] 8. In this example, the specification and release interface supports individual releases, releases of artifact sets, and general releases of all changes.

[0111] 9. Only published changes are ultimately adopted in the corresponding additional model views.

[0112] The application of the methods described in this paper is not limited to system development. For example, the aforementioned automated coupling between static, functional perspectives and dynamic behavioral descriptions can be used for various development activities within the V-model described above. On one hand, this method, or the software tools implementing it, can be used to develop individual system functions or parts thereof, because change tracking and control can be achieved through the semantic coupling of the various model view elements in a software tool-assisted manner. Therefore, this method facilitates detailed interpretation of system designs or the development of implementation methods. However, it can also be used to develop automated systems or for integration testing, or to determine suitable stimuli and associated system responses during the validation phase.

Claims

1. A computer-implemented method for developing and / or validating executable specifications for system development and / or system verification of functional systems for target devices, particularly motor vehicles, the method comprising the following steps: - Provide (S1) at least one model view of a functional system including one or more functions (F, F1, F2, F3, F4) for controlling or regulating the target device; - Provide a selection interface (S2) designed for users to select and modify system components within a provided first model view, wherein, The first model view includes a static functional system description (M1), which includes at least one functional causal chain (W1, W2, W3, W4) describing the causal relationship between influence parameters and target parameters relating to the physical functionality in the target device. The selection and modification of the system portion includes selecting and modifying at least a portion of the functional causal chain (W1, W2, W3, W4) in the static functional system description (M1). - The system parts selected and / or modified in the first model view, in particular the modifications made and / or their effects and / or dependency shifts in the rest of the system, will be displayed (S3) in at least one corresponding additional model view for the user, wherein the at least one corresponding additional model view includes a dynamic behavior description (M3) that includes a simulation of the dynamic behavior of the system generated using simulation software, wherein, for the selection and modification of at least a portion of the functional causal chain (W1, W2, W3, W4), a functional body is automatically generated in the dynamic behavior description (M3) of the at least one corresponding additional model view; - Provide (S4) a specification and release interface, which is designed to select and / or inspect and / or further adapt to system parts or changes displayed in the at least one corresponding additional model view and is designed to be released by the user to the changes to the system made in the first model view and / or the at least one corresponding additional model view. - The published changes to the system are automatically applied to at least one corresponding additional model view.

2. The method of claim 1, wherein, in addition to the selected and / or modified functions (F, F1, F2, F3, F4), the defined dependencies of the functions, especially the interfaces (C, C1, C2, C3) and their descriptions, are also transformed into a corresponding additional model view and the defined dependencies of the functions are displayed to the user therein.

3. The method according to claim 1 or 2, wherein the first model view and the at least one corresponding additional model view further include two or more of the following model views of the functional system: - Functional architecture (M2), in which the functional common parts (G) of different causal chains (W1, W2, W3) are aggregated and arranged hierarchically according to functional subordination; -Technical architecture, in which the common parts of different causal chains are aggregated and arranged hierarchically according to technical subordination; - Requirements engineering, which in particular refers to the technical requirements for each part of the system.

4. The method according to claim 3, wherein - The user selects and / or changes the entire functional causal chain (W1; W2; W3; W4) or one or more parts of the causal chain in the static functional system description (M1) via the selection interface; - In the transformation step, for each of the selected and / or modified parts of the causal chain (W1; W2; W3; W4), the functional entity in the dynamic behavior description (M3) is automatically generated and / or selected from the existing functional entity inventory and displayed to the user using simulation software. -The specifications and release interface are preferably also designed to be modified in the dynamic behavior description (M3) and to feed the changes back to the static functional system description (M1) and / or to the functional architecture (M2) to check for any inconsistencies.

5. The method of claim 4, wherein the specification and release interface are further designed to: provide the user with a choice among the following options for the system portion to be fed back: - All functions (F, F1, F2, F3, F4) and interfaces (C, C1, C2, C3); - All functions (F, F1, F2, F3, F4) and all related interfaces (C, C1, C2, C3) up to the level of detail that the user wishes to define via the specification and release interface, or all major functions having the related interfaces; - The functions and interfaces that the user chooses through the specifications and release interface.

6. The method according to claim 1 or 2, wherein the method includes checking for changes to the same part (G) of the function in different causal chains (W1, W2, W3) included in the functional architecture (M2) and / or in the specification and release interface, and, in the absence of a match, displaying to the user the optional provision of options for changes to matching functional variants.

7. The method according to claim 1 or 2, wherein the inspection in the specification and release interface includes the user's request to contact an organizational unit suitable for the required inspection or release.

8. A control unit comprising a processor configured to implement the method according to any one of claims 1 to 7.

9. A software tool comprising instructions that, when executed in a control unit or a data processing device, cause the control unit or the data processing device to perform the method according to any one of claims 1 to 7.

10. A machine-readable storage medium having stored thereon the software tool according to claim 9.

Images