Technical system according to specification by formal language with common logic

Abstract

Technical systems according to specifications through formal languages with common logic. A first aspect of the present disclosure relates to a computer-implemented method for manufacturing a normative technical system, in particular a normative at least partially autonomous driving vehicle or a part thereof, comprising: receiving time-related data from at least one test of the technical system; translating the time-related data into a first specification in a first form language at a first abstraction level, wherein the first form language has a first semantics defined by a first interpretation mapping from the first form language to logic; receiving a second specification in a second form language at a second abstraction level, wherein the second form language has a second semantics defined by a second interpretation mapping from the second form language to the logic; and checking how the first specification and the second specification exhibit relative to each other based on a logical implication.

Description

Background Art

[0001] In complex, safety-critical technical systems, such as autonomous systems (e.g., for autonomous driving, human-machine collaboration in industrial manufacturing, etc.), specifications are used for documentation, product development, safety protection (e.g., through testing methods), and are part of the necessary approval argumentation.

[0002] Typically, specifications are used in a top-down approach, i.e., a specified product (software and / or hardware) is developed starting from the specification. The development along the known V-model is an example established, for instance, in the automotive industry of a refinement process in the sense of the development process from the specification to the product, yet not necessarily a refinement of the specification itself. Independently of the V-model, it may also be necessary and / or useful to express specifications at different levels of abstraction. In particular, it may be necessary and / or useful to refine a specification at a higher level of abstraction into a specification at a lower level of abstraction. At the same time, it may in particular be necessary and / or useful to abstract (i.e., generalize) a specification at a lower level of abstraction into a specification at a higher level of abstraction.

[0003] In industrial practice, specifications are usually described informally, e.g., in natural language, in a requirements management tool such as IBM / DOORS. This requires a number of mostly manual steps to ensure the consistency of the product with the specification, and then the consistency cannot be formally guaranteed at any time. Here, automatic refinement and / or abstraction of the specification is not possible. Summary of the Invention

[0004] Therefore, the problem on which the present disclosure is based is to automatically provide the refinement and / or abstraction of one or more specifications.

[0005] Formal specification languages, such as Z, B, and Event-B, allow for the stepwise refinement of specifications in order to establish provable associations between specifications at different levels of abstraction using formal methods (semi-automatically using theorem provers or automatically using model checking). However, the above languages are not suitable for representing specifications based on temporal logics, such as LTL (Linear Temporal Logic). In addition, in the case of the above formal specification languages, the specifications still have to be manually formulated at different levels of abstraction before it is possible to check, for example (automatically), whether these specifications are correct refinements or abstractions.

[0006] Therefore, the problem on which the present disclosure is additionally based is to automatically generate consistent specifications at at least one level of abstraction, in particular at different levels of abstraction. Thus, a specification hierarchy should be established.

[0007] Therefore, the overarching problem on which the present disclosure is based is to manufacture a technical system according to the specification.

[0008] The problems mentioned above are solved by the framework proposed in the present disclosure, in which specifications are expressed or can be expressed at different levels of abstraction by formal languages. These formal languages can each have a semantics based on a common logic. The framework proposed here has differed from known methods in the following respects: specifications can be written in different formal languages, which can be syntactically represented by a common term structure and semantically fixed by a common logic (e.g., by temporal logic) respectively. By means of this common logic (subsequently usually only referred to as logic), refinement and abstraction can be defined, for example. A refinement or abstraction can be a translation from a formal language at one level of abstraction to another formal language at one level of abstraction. These translations can be carried out in a computer-implemented manner and thus automatically.

[0009] A first general aspect of the present disclosure relates to a computer-implemented method for manufacturing a technical system according to a specification, in particular for manufacturing at least a partially autonomous vehicle or parts thereof according to a specification. The method includes receiving time-related data from at least one test of the technical system. The method further includes: translating the time-related data into a first specification in a first formal language at a first level of abstraction, wherein the first formal language has a first semantics defined by a first interpretation mapping from the first formal language to the logic. The logic can be decidable. The method further includes: receiving a second specification in a second formal language at a second level of abstraction, wherein the second formal language has a second semantics defined by a second interpretation mapping from the second formal language to the logic. The method may further include: checking how the first specification and the second specification behave relative to each other based on logical implication. For example, the method may, for this purpose, check to what extent the first specification covers the second specification and / or to what extent the second specification covers the first specification based on logical implication.

[0010] A second general aspect of the present disclosure relates to a computer system designed to execute the computer-implemented method for manufacturing a technical system according to a specification, in particular for manufacturing at least a partially autonomous vehicle or parts thereof according to a specification according to the first general aspect (or an implementation thereof).

[0011] A third general aspect of the present disclosure relates to a computer program designed to execute the computer-implemented method for manufacturing a technical system according to a specification, in particular for manufacturing at least a partially autonomous vehicle or parts thereof according to a specification according to the first general aspect (or an implementation thereof).

[0012] A fourth general aspect of the present disclosure relates to a computer-readable medium or signal that stores and / or contains the computer program according to the third general aspect (or an implementation thereof).

[0013] A specification (such as a first specification and / or a second specification, and thus each specification) can include or be a characterization of the behavior of a system over time. The system behavior can be the behavior of a technical system (in accordance with the specification). A specification can include one or more requirements for the behavior of a system over time. A specification can already be formulated in a formal language at an abstract level. Alternatively, a specification can first be a natural language specification at an abstract level and then be translated into a formal language (at that abstract level). The translation can include one or more refinements and / or one or more abstractions. Alternatively or additionally, the translation can include the translation of time-related data from at least one test of a technical system.

[0014] The abstract levels can be arranged according to a partial order of the abstract levels. The partial order of the abstract levels can include at least one lower and one higher abstract level. The abstract levels and, if necessary, their arrangement according to the partial order can be specified by expert knowledge. The closer an abstract level is to at least one test of a technical system, the lower that abstract level can be.

[0015] A formal language can be an abstract language in which, unlike natural language, the emphasis (often) is not on communication but on the definition and application of a formal system in a narrower sense and logic in a broader general sense. A formal language consists of a defined set of strings, which can be called the words of the language and can consist of a character set (also called an alphabet). The alphabet does not necessarily have to be an alphabet known in linguistics (a, b, c, …). A formal language over an alphabet can be a subset of the Kleene hull (Kleenschen Hülle) of the alphabet. In addition to such syntax, the semantics of a formal language can be defined.

[0016] The refinement and / or abstraction of one or more specifications form the core aspects of the framework presented here. After the instantiation of the framework and the formal proof of correctness, one or more refinements and / or one or more abstractions can be performed automatically.

[0017] In addition to the top-down scheme (in view of the abstract levels), the framework implements an automated bottom-up scheme (also in view of the abstract levels), i.e., system behavior observed, for example, in the form of on-site measurements can be generalized to abstract behavior. Such a set of abstract behaviors can be understood as a specification as in the method according to the first general aspect (or its implementation). A special case of this generalization can be the recognition of abstract scenarios of driving data. Another example in this context can be the reconstruction of driving scenarios in a simulation environment.

[0018] The framework presented here, and in particular the method according to the first general aspect (or its implementation), enables the consistent development of specifications at different levels of abstraction. This makes it easy for specification developers to quickly and correctly formulate requirements at the corresponding levels of abstraction. The automatic and consistent translation to other levels of abstraction provides feedback to the specification developers, which facilitates the validation of the developed specifications.

[0019] Based on manually developed as well as automatically generated specifications, one or more quantitative monitors can be generated, for example, with the help of which tests can be automatically generated by an optimization method. This thus enables the (informal) proof of the desired characteristics in the product, for example.

[0020] For each level of abstraction, (generally) specific formal languages are used, or even multiple formal languages are used at one level of abstraction, based on a common term structure. Each language can be understood as a DSL (Domain-Specific Language), which enables the effective expression of the core of the corresponding level of abstraction. The framework for abstraction and / or refinement can reduce the effort required to ensure the consistency between the specification and the product / implementation. Thus, for example, the corresponding parts of the software can be directly generated based on the specification at the appropriate level of abstraction, such as the software for a behavior planner for an automated vehicle or a monitor for identifying potentially problematic future situations, based on the specification of the behavior of at least partially automated vehicles. The framework for abstraction and / or refinement and in particular the method according to the first general aspect (or its implementation) also allows the recorded field data (such as driving condition data) to be represented in the form of "formulas" at different levels of abstraction that are understandable to the specification developers. Thus, on the one hand, a large amount of time-related data (also called field data, such as driving data) from at least one test of a technical system can be assigned to multiple equivalence classes regarding different levels of abstraction. On the other hand, the data can thus be more easily interpreted regarding its representativeness. This enables the identification of missing specifications. Here, for example, the following situations can be distinguished: specifications that are included in the data but have not been formulated in the specification so far, unfulfilled specifications (specifications formulated in the form of "if-then-rules" for which "then" is violated by the data), and incomplete field data (specifications in the form of "if-then-rules" for which "if" is not covered by any data).

[0021] These features enable the design of a device for testing complex technical systems, such as at least partially autonomous vehicles or parts thereof, with the aim of efficiently using test expenditures (such as test drives) with respect to the coverage of a given set of specifications / requirements. For this purpose, for example, in an iterative process, first, the smallest possible number of tests (such as driving maneuvers) of the technical system can be determined, which cover all manually formulated and automatically generated specifications at different levels of abstraction. For this purpose, for example, a suitable DOE (Design of Experiments) method can be used to construct an initial set of one or more tests of the technical system. For each test, after its execution, the result (i.e., measurement and / or simulation) can be automatically expressed by abstraction in all levels of abstraction. If this abstraction of the measurement (such as a first specification in the method according to the first general aspect (or an embodiment thereof)) is consistent with the specification to be covered (such as a second specification in the method according to the first general aspect (or an embodiment thereof)), then the abstraction of the measurement satisfies the specification. The framework for abstraction and / or refinement thus enables the automatic verification of multiple specifications at different levels of abstraction by means of one test. If the abstraction of the test satisfies the specification, then in the simplest case, the specification can be considered to be covered by the test. Since the test is expressed in the formal language of the specification (in the first formal language in the method according to the first general aspect (or an embodiment thereof)) by abstraction, it also follows that there is a possibility of more precise consideration: thus, for example, it can be ascertained whether the abstraction completely or only partially covers the specification. In the latter case, if necessary or if desired, at least one additional test of the technical system can be automatically generated, for example, in such a way that the part of the specification that is not covered by the abstract of the test is refined. If the abstraction of the test is inconsistent with the specification, then it can be distinguished and in particular ascertained whether it actually concerns an error in the product, whether the specification is incorrect, or whether there is an obvious inconsistency through the abstraction of the test.

[0022] The method according to the first aspect (or an embodiment thereof) proposed in the present disclosure enables, for example, the development of specifications in an iterative process, which can benefit from formal refinement and abstraction relationships. Observations in the form of, for example, field data (time-dependent data) of the specified technical system can also contribute to this. Put in a suitable form, these field data can be understood as elements of a refined specification language (close to ⊥ in a partial order, i.e., a language at a low level of abstraction). By abstraction, the representation can be automatically translated into multiple formal languages, which can be achieved by abstraction in the partial order. Each of these data specifications d can be associated with a specification s created manually or automatically by refinement or abstraction. Here, an examination of how the first specification and the second specification behave relative to each other can, for example, yield the following results:

[0023] If for example it is shown that a second specification s (i.e. a pre-given specification for example) covers a first specification d (i.e. a data specification), i.e. applies, the abstraction of the data is covered by the pre-given specification. And if this does not apply, the specification developer can for example by means of check whether an extension of the pre-given specification is necessary or whether this is intentionally excluded.

[0024] If alternatively or additionally it is shown that the first specification d (i.e. the data specification) covers the second specification s (i.e. a pre-given specification for example), i.e. applies, the pre-given specification is covered by the abstraction of the data. If this does not apply, one or more additional tests for the technical system can be found by automatic refinement in the direction of a formal language approaching ⊥ in the proximity partial order in order to generate missing data.

[0025] The method according to the first general aspect (or an embodiment thereof) can include performing said one or more additional tests. Description of the Drawings

[0026] Figure 1a Schematically illustrate an exemplary embodiment of a computer-implemented method for manufacturing a technical system according to a specification.

[0027] Figure 1b Schematically illustrate an exemplary embodiment of a computer-implemented method for manufacturing a technical system according to a specification, wherein time-related data from at least one test of the technical system is translated into a third specification (as an intermediate step) and thereafter into a first specification.

[0028] Figure 1c Schematically illustrate an exemplary embodiment of a computer-implemented method for manufacturing a technical system according to a specification, wherein a fourth specification (as an intermediate step) is translated into a second specification.

[0029] Figure 1d Schematically illustrate an exemplary embodiment of a computer-implemented method for manufacturing a technical system according to a specification, wherein time-related data from at least one test of the technical system is translated into a third specification (as an intermediate step) and thereafter into a first specification, and wherein a fourth specification (as an intermediate step) is translated into a second specification.

[0030] Figure 2 Schematically illustrate the abstraction levels of at least time-related data, a first specification and a second specification.

[0031] Figure 3Schematically illustrate at least a first interpretation mapping and a second interpretation mapping, wherein the first interpretation mapping maps a first formal language into logic and the second interpretation mapping maps a second formal language into (the same) logic.

[0032] Figure 4 Schematically illustrate a driving scenario at an intersection of a vehicle with at least partial autonomous driving and another traffic participant.

[0033] Figure 5 Schematically illustrate multiple formal languages at partially different levels of abstraction and the refinement between said formal languages.

[0034] Figure 6 Show exemplary kinematic variables with respect to a prediction time.

[0035] Figure 7 Show an exemplary transformation of a position interval from a local coordinate system to a global coordinate system.

[0036] Figure 8 Show an exemplary transformation of a straight road from a local coordinate system to a global coordinate system. Detailed Description

[0037] The advantages described are achieved by providing various formal languages based on a common term structure, which allow specifications to be expressed at different levels of abstraction. These formal languages are based on a common logic that defines the semantics, i.e., the meaning, of these formal languages. Specifications in a formal language can be automatically translated into consistent specifications in other formal languages. Here, two directions are distinguished: abstraction and refinement.

[0038] Figure 5 Exemplarily and schematically show multiple levels of abstraction (rounded boxes), where the higher the level of abstraction is presented in Figure 5 the more above, the higher the level of abstraction in view of its degree of abstraction. At least one formal language can be defined for each level of abstraction. Also show an exemplary assignment of a first formal language 11 and a third formal language 31. Thus, Figure 5 for example, formal languages for specifications in the context of at least partial autonomous driving for relevant traffic situations and scenarios (fixed pre-given sequences of traffic situations) can be presented. These formal languages can form a partial order with respect to refinement. For the relation S j →S k , each valid specification in language S j can be transformed into a corresponding refined specification in language S k . When transforming a specification in the opposite direction of the arrow direction, abstraction is referred to. It should be noted that for every refinement, there does not necessarily have to be an abstraction, and vice versa.

[0039] A framework for abstraction and / or refinement can be described by a variety of formal languages S 1 ,..., S n (at least two formal languages), where an abstraction or refinement relationship can exist between two formal languages S j , S k . The formal language S j can be syntactically understood as a set of terms implemented by the following simple rules (e.g., in Backus-Naur form):

[0040] Term ::= Symbol|Term(Term,..., Term)

[0041] The set of allowed terms of the formal language can be restricted here syntactically or via a type system. The syntactic structure can be defined, for example, by frameworks such as Xtext, meta-programming languages such as Racket, or theorem provers such as Lean 4.

[0042] The valid terms t ∈ S j of the formal language S j (also called well-formed terms) obtain their meaning through an interpretation mapping I j . In order to be able to define such an interpretation mapping, a semantic basis is first stipulated for all languages S 1 ,..., S n of the variety of formal languages. One manifestation of this semantics is to stipulate a specific logic L. This logic L is also called the common logic. As the logic L, for example, temporal logic such as linear temporal logic (LTL) or signal temporal logic can be considered. Alternatively or additionally, temporal logic can be combined with arithmetic theories such as linear real arithmetic or real polynomial arithmetic. In this way, for example, the changes of geometric objects over time can be described. Syntactically, the logic can also be understood as a set of terms.

[0043] For (especially each) formal language S j , an interpretation mapping I j from the formal language S j to the logic L can be inductively defined via the term structure of S j : S j → L, where the term structure stipulates the semantics of the language by the logic L. The interpretation mapping I j thus translates each term s ∈ S j into a term l = I j (s) ∈ L of the logic L. The term l = I j (s) ∈ L can be called the semantic interpretation of s ∈ S jExplanation. The terms of logic also denote statements. Advantageously for the automizability of the abstraction / refinement framework, the logic L is decidable. That is, there always exists an algorithm which, given two terms (also called statements) l 1 , l 2 ∈ L, decides whether the statement l 1 logically implies the statement l 2 , i.e., whether logical implication applies. If and only if, for example, with the help of a deductive system consisting of the axioms and derivation rules of the logic L, the statement l 2 can be formally derived from the statement l 1 , the statement l 1 of the logic L can logically imply the statement l 2 of the logic L, i.e., (where is logical implication). The symbol is not a symbol of logic 50,L and, in particular, is not a binary operator of logic 50,L. In particular, the symbol is not the implication (or →) within logic 50,L. Instead, the symbol relates the statements of logic 50,L to one another. In other words, the total statement is not part of logic 50,L but lies outside. Logical implication can be a semantic inference and / or a syntactic inference (also called a derivation relation). In the context of temporal logic (in particular, LTL supplemented with a decidable arithmetic theory), there exists such an algorithm by reduction to a decision problem in automata theory. If the logic is undecidable, the framework can still be applied within the scope where there exists an algorithm as described above for the implication to be computed. The formal language with an interpretation mapping to logic L,50 is schematically illustrated in Figure 3 .

[0044] If and only if , the formal language S k can be refined to the formal language S j：k by means of the mapping R j : S k → S j (notation: ). The mapping R j，k is a refinement. Thus, a refinement from one formal language (S j ) to another formal language (S k ) can be a mapping (R j ) from one formal language (S k ) to another formal language (S j，k ), where the other formal language (Sk )'s explanatory mapping (I k ) and the mapping (R j ) on each term (s) of a formal language (S j，k ) respectively imply the explanation (I j (s)) of that term (s).

[0045] If and only if the formal language S j can be abstracted with the aid of the mapping A k，j : S k →S j (Notation: ) to abstract the formal language S k . The mapping A k，j is an abstraction. Thus, the abstraction from one formal language (S k ) to another formal language (S j ) can be a mapping (A k ) from one formal language (S j ) to another formal language (S k，j ), where the explanatory mapping (I j ) of the other formal language (S j ) and the mapping (A k ) on each term (s) of a formal language (S k，j ) respectively imply the explanation (I k (s)) of that term (s).

[0046] The languages S 1 ,..., S n can form a partial order each with respect to the relation (refinement) or (abstraction). If for each relation there exists a relation and vice versa, then the two partial orders are the same. Here, both refinement and abstraction are transitive, that is and This allows automatically refining or abstracting a term across multiple languages (through cascades of multiple refinements or abstractions).

[0047] The correctness of each refinement or abstraction relation can be formally shown, for example, by induction on the corresponding term structure with the aid of a theorem prover. Here, it can be utilized that: logical implication can be automatically determined.

[0048] Now a computer-implemented method 100 for manufacturing a technical system according to a specification is disclosed (in Figures 1a - 1dillustrated schematically). The computer-implemented method 100 can in particular be a method for manufacturing at least partially autonomous vehicles or parts thereof according to a specification. The technical system can be a cyber-physical system. The technical system can be an at least partially autonomous system. For example, the technical system can be an at least partially autonomous vehicle or a part thereof.

[0049] The method 100 includes receiving 110 at least one time-related data 1 from the technical system. The time-related data 1 can for example include or be measurement and / or simulation data.

[0050] The method 100 furthermore includes translating 120 the time-related data 1 into a first specification 10 in a first formal language 11 at a first level of abstraction, where the first formal language 11 has a first semantics defined by a first interpretation mapping 12 from the first formal language 11 to a logic 50, where preferably the logic 50 is decidable. The first specification 10 can be referred to as a data specification. The first level of abstraction can for example be a low or the lowest level of abstraction (with respect to the partial order of abstraction). On the other hand, the first level of abstraction can also be a high or the highest level of abstraction (with respect to the partial order of abstraction). Figure 2 Schematically shows an assignment where the first level of abstraction is not among the two lowest levels of abstraction. The attribute "first" in "first level of abstraction" does not necessarily denote the first element in the partial order of abstraction and / or refinement. In other words, any level of abstraction of such a partial order can be the first level of abstraction in the sense of step 120.

[0051] The method 100 furthermore includes receiving 130 a second specification 20 in a second formal language 21 at a second level of abstraction, where the second formal language 21 has a second semantics defined by a second interpretation mapping 22 from the second formal language 21 to the logic 50. The second specification 20 can be a pre-given specification. A specification can be pre-given when it is given at the latest at the time of performing the (corresponding) method step for which it is processed (here, step 140) and is in particular ready for the (corresponding) method step. Thus, different from what is schematically presented in Figures 1a - 1d step 130 can also be performed before step 120 or together with step 110 or before step 110. In particular, the second specification 20 does not have to be translated according to the time-related data 1 from step 110. The second level of abstraction can for example be a high or the highest level of abstraction (with respect to the partial order of abstraction). On the other hand, the second level of abstraction can also be a low or the lowest level of abstraction (with respect to the partial order of abstraction). Figure 2The assignment is again schematically shown, wherein the second level of abstraction is located at a certain level of abstraction. The attribute "second" in the "second level of abstraction" again does not necessarily represent the second element in a partial order of abstractions and / or refinements. In other words, any level of abstraction of such a partial order can be a second level of abstraction in the sense of step 130.

[0052] The first specification and / or the second specification may each be a representation of the system behavior (ie, the behavior of the technical system) over time. The first specification may be an actual specification. The second specification may be a target specification.

[0053] Method 100 may include based on logical implications (Based on logic 50) Check 140: How the first specification 10 and the second specification 20 behave relative to each other. In particular, the method 100 may include for this purpose: Check: to what extent 141 (in particular whether) the first specification 10 covers the second specification 20 and / or to what extent 142 (in particular whether) the second specification 20 covers the first specification 10. Figures 1a - 1d In the example, “OK” indicates whether the first specification 10 covers the second specification 20 , and “nOK” indicates whether the first specification 10 does not cover the second specification 20 , and so on.

[0054] In other words, method 100 may include based on logical implications Check: to what extent 141 (in particular whether) the first specification 10 covers the second specification 20. Alternatively or additionally, the method 100 may include a check based on logical implications. Check: to what extent 142 (in particular whether) the second specification 20 covers the first specification 10. Alternatively or additionally, the method 100 may include a check based on logical implications. Check to what extent 141 (in particular whether) the first specification 10 covers the second specification 20 and to what extent 142 (in particular whether) the second specification 20 covers the first specification 10 .

[0055] As already discussed in the context of a more general framework for refinement and / or abstraction, in particular from a syntactic point of view, a formal language may include or be a collection of terms. The collection of terms may be subject to one or more rules. That is, only terms that satisfy the one or more rules are components of the formal language and are therefore valid terms. A formal language may have semantics defined by an interpretation mapping from the formal language to a logic. At least two formal languages ​​(and in particular formal languages ​​of a plurality of formal languages) may each have semantics, wherein each semantics is defined by a corresponding (i.e., generally, unique) interpretation mapping from the corresponding formal language to the logic. This is in Figure 3is schematically illustrated. The evaluation of the interpretation mapping of the terms of a formal language can be referred to as the interpretation of the terms. Logic can be regarded as the basis for describing semantics for each formal language. Due to this logic, expressions in different formal languages can be related. Thus, it can be checked 140: how the first specification 10 and the second specification 20 behave relative to each other.

[0056] A specification A (e.g., the first specification 10) in one formal language (e.g., in the first formal language 11) can cover a specification B (e.g., the second specification 20) in another formal language (e.g., in the second formal language 21, but this other formal language can also be the first formal language) in the following case: the interpretation of the specification B (e.g., I 2 (B)) implies the interpretation of the specification A (e.g., I 1 (A)), i.e., for example Here, A and B can be understood as general placeholders for the terms of the respective formal languages. In this case, for example, I 1 : S 1 → L and I 2 : S 2 → L are the corresponding interpretation mappings from the first formal language S 1 , 10 and the second formal language S 1 , 20 to the logic L, 50.

[0057] For example, if and only if then the first specification d (data specification) covers the second specification s (predetermined specification), where is logical implication, where in this example, I = I 1 : S 1 → L is the interpretation mapping from the first formal language S 1 to the logic L. On the other hand, for example, if and only if then the second specification s covers the first specification d.

[0058] As already discussed in the context of a more general framework, if and only if, for example, with the help of a deductive system consisting of axioms and derivation rules, the statement l 2 can be formally derived from the statement l 1 then the statement l 1 of the logic L can imply the statement l 2 of the logic L, i.e., the statement l 1 , l 2 of the logic L can be formed, for example, through the interpretation mapping I, i.e., for example, l 1 = I(B), l 2 = I(A).

[0059] Logical implication It can be based on logic 50 at least to the extent that logical implications relate statements of the logic 50. Thus, method 100 can include applying a first interpretation mapping 12 to a first specification 10, where a first statement of logic 50 is produced. Method 100 can further include applying a second interpretation mapping 22 to a second specification 20, where a second statement of logic 50 is produced. Checking 140 for logical implications, e.g., how the first specification 10 and the second specification 20 behave relative to each other, can include applying logical implications to the first statement of logic 50 and the second statement of logic 50, in particular whether and / or to what extent the first statement of logic 50 logically implies the second statement of logic 50 (and / or vice versa).

[0060] The first level of abstraction can, but need not be, the second level of abstraction. In an exemplary Figure 2 one, the second level of abstraction is lower than the first level of abstraction (with respect to the partial order of abstraction). However, different from what is schematically presented in Figure 2 it, the second level of abstraction can also be higher than the first level of abstraction (with respect to the partial order of abstraction) or exactly at the same level of abstraction.

[0061] The first formal language 11 can be the second formal language 21 especially if the first level of abstraction is the second level of abstraction. On the other hand, even if the first level of abstraction is the second level of abstraction, the first formal language and the second formal language can be different.

[0062] If the first formal language is the second formal language, the first semantics can also be the second semantics. In this case, then the first interpretation mapping is also the second interpretation mapping. And if the first formal language and the second formal language are different, then the first semantics and the second semantics can (and usually) be different. In this case, then the first interpretation mapping and the second interpretation mapping are different.

[0063] The logic L, 50, i.e., the common logic, can be a temporal logic. In particular, the logic can be a linear temporal logic (also known as lineare temporale Logik) or a signal temporal logic.

[0064] Alternatively or additionally, the logic can include one or more (decidable) fragments of predicate logic. In particular, the logic can include one or more decidable fragments of predicate logic, the decidability of which can be reduced to a decidable "satisfiability modulo theories" problem, and / or a combination consisting of at least one such fragment of temporal logic and predicate logic.

[0065] Advantageously, the logic is decidable. On the other hand, it can be possible to still implement the method 100 at least to the extent that the expression of the logic is decidable, i.e., logical implication (with respect to the logic) is decidable.

[0066] Translating time-related data 1 into a first specification 10 in a first formal language 11 at a first level of abstraction 120 can include, as schematically illustrated, for example, in Figure 1b and Figure 1d : First, translating time-related data 1 into a third specification 30 in a third formal language 31 at a third level of abstraction 121, where the third formal language 31 has a third semantics defined by a third interpretation mapping 32 from the third formal language 31 to logic 50. Thereafter, translating the third specification 30 into the first specification 10.

[0067] The third level of abstraction can be, as schematically illustrated, for example, in Figure 2 the lowest level of abstraction (with respect to the partial order of abstractions) or a low level of abstraction (with respect to the partial order of abstractions). On the other hand, the third level of abstraction can again be any level of abstraction in the partial order of abstractions and / or refinements. Translating the third specification 30 into the first specification 10 can be an abstraction or a refinement, as schematically presented in Figure 2

[0068] Method 100 can include a cascade of multiple translation steps (e.g., more than 2, more than 3, more than 4, more than 5, more than 10, more than 50) from a third specification 30 in a third formal language 31 at a third level of abstraction to a first specification 10 in a first formal language 11 at a first level of abstraction. The cascade can include one or more abstractions. Alternatively or additionally, the cascade can include one or more refinements. For example, the cascade can include not only one or more abstractions but also one or more refinements. For example, the third specification 30 can first be abstracted to a specification at a higher level of abstraction than the first level of abstraction and then refined to the first specification 10 at the first level of abstraction.

[0069] Alternatively or additionally, receiving 130 a second specification 20 in a second formal language 21 at a second level of abstraction can include, as schematically illustrated, for example, in Figure 1c and Figure 1d : First, receiving 131 a fourth specification 40 in a fourth formal language 41 at a fourth level of abstraction [DESCR: e.g., a higher level of abstraction], where the fourth formal language 41 has a fourth semantics defined by a fourth interpretation mapping 42 from the fourth formal language 41 to logic 50. Thereafter, translating the fourth specification 40 into the second specification 20.

[0070] The fourth level of abstraction can be, as schematically illustrated, for example, in Figure 2as illustrated schematically therein is the highest level of abstraction (with respect to an abstract partial order) or a higher level of abstraction (with respect to an abstract partial order). On the other hand, the fourth level of abstraction can again be any level of abstraction of an abstract and / or refined partial order. Translating the fourth specification 40 to the second specification 20 can be an abstraction or can be a refinement as presented schematically in Figure 2 therein.

[0071] The fourth specification 40 can be the same as the second specification 20, but does not have to be a pre-given specification. A specification can be pre-given when it is given at the latest at the moment of implementing the (corresponding) method step (here, step 132) for processing it and is in particular prepared for the (corresponding) method step. In particular, the fourth specification 40 does not have to be translated according to the time-related data 1 from step 110.

[0072] The method 100 can include a cascade of a further plurality of translation steps (e.g., more than 2, more than 3, more than 4, more than 5, more than 10, more than 50) from a fourth specification 40 in a fourth formal language 41 at a fourth level of abstraction to a second specification 20 in a second formal language 21 at a second level of abstraction. The further cascade can include one or more refinements. Alternatively or additionally, the cascade can include one or more abstractions. For example, the cascade can include not only one or more refinements but also one or more abstractions. For example, the fourth specification 40 can first be refined to a specification at an abstraction level lower than the second level of abstraction and then be abstracted to the second specification 20 at the second level of abstraction.

[0073] As presented schematically in Figure 1d therein, the method 100 can include not only translating the third specification 30 to the first specification 10 but also translating the fourth specification 40 to the second specification 20.

[0074] In the method 100 presented in the present disclosure, due to the common logic, two specifications (the first specification 10 and the second specification 20) in the same formal language or in different formal languages can be related (e.g., compared), where at least one of the specifications (i.e., the first specification 10) has been translated 110 according to the time-related data 1 and where the two specifications have optionally been translated according to further specifications by the cascade and / or the further cascade.

[0075] One or more possible checks are disclosed below, which can be carried out within the check 140 as presented schematically, for example, in Figures 1a - 1d therein, but do not have to be.

[0076] In method 100, for example, it can be checked 141 whether the first specification 10 (i.e., data specification d) covers the second specification 20 (i.e., for example, a pre-given specification s). Thus, it can be checked here whether or if the first language is a second language with the same semantics (I 1 = I 2 = I), then whether Then, for example, the approval of the technical system can be made to depend on, in particular on the premise that, the first specification 10 covers the second specification 20. Thus, this condition can be a necessary condition (among possibly multiple necessary conditions) for approving the technical system. This condition can, but does not have to be, also sufficient for the approval of the technical system, that is, if this condition is met, then the technical system is approved. If the first specification (i.e., data specification) covers the second specification, then the specification is tested in view of the first abstraction level by means of at least one test of the technical system.

[0077] Alternatively or additionally, in method 100, it can be checked 142 whether the second specification 20 (i.e., for example, a pre-given specification s) covers the first specification 10 (i.e., data specification d). Thus, it can be checked here whether or if the first language is a second language with the same semantics (I 1 = I 2 = I), then whether Again, the approval of the technical system can be made to depend on, in particular on the premise that, the second specification 20 covers the first specification 10. Thus, this condition can also be a necessary condition (among possibly multiple necessary conditions) for approving the technical system. This condition can, but does not have to be, also sufficient for approving the technical system, that is, if this condition is met, then the technical system is approved. If the second specification covers the first specification, then the technical system behaves in accordance with the specification with respect to at least one test of the technical system.

[0078] A prerequisite for the approval of the technical system can be that not only does the second specification cover the first specification but also the first specification covers the second specification. In this case, method 100 includes two checks. These conditions can, but do not have to be, sufficient.

[0079] Alternatively or additionally, in method 100, it can be checked 143 based on logical implication whether a first part of the first specification 10 (i.e., data specification d) exceeds the second specification 20 (i.e., for example, a pre-given specification s). This check can in particular be carried out as schematically illustrated, for example, in Figures 1a - 1d in the case where the first specification 10 covers the second specification 20 and / or in the case where the second specification 20 does not cover the first specification 10. On the other hand, different from in Figures 1a - 1dAs schematically illustrated, method 100 may include an inspection 143: whether a first part of a first specification exceeds a second specification, instead of an inspection: to what extent the first specification covers the second specification 141 and / or to what extent the second specification covers the first specification 142.

[0080] If there is such a first part, method 100 may include: according to a formula such as or if I 1 = I 2 = I, then extend the second specification 20 with the intersection of the first specification 10 and the negated second specification, where represents negation and ∧ represents AND in logic L,50. Method 100 may include translating the extended specification, i.e., the second specification 20 merged with this extension, to another abstraction level. This translation may be performed by abstraction and / or refinement.

[0081] Method 100 may include an inspection: whether it is allowed to extend the second specification with this intersection. In particular, method 100 may (e.g., via a user interface) make the extension of the second specification depend on the consent of the user of method 100. For example, it is conceivable to intentionally exclude the extension of the second specification.

[0082] Alternatively or additionally, especially in the case where the second specification does not cover the first specification, it may be checked: whether there is an error in the technical system, whether the second specification (or the fourth specification) has an error, and / or whether there are obvious inconsistencies in the time-related data of at least one test from the technical system through translation (especially through abstraction).

[0083] Alternatively or additionally, in method 100, an inspection 144 may be performed based on logical implication : whether a second part of the second specification 20 (i.e., for example, a pre-given specification s) exceeds the first specification 10 (i.e., the data specification d). This inspection may in particular be performed as schematically illustrated, for example, in Figures 1a - 1d in the case where the second specification covers the first specification and / or in the case where the first specification does not cover the second specification. On the other hand, different from what is schematically illustrated in Figures 1a - 1d method 100 may include an inspection 144: whether a second part of the second specification exceeds the first specification, instead of an inspection: whether the first specification covers the second specification 141 and / or whether the second specification covers the first specification 142.

[0084] If there is such a second part, method 100 may include: according to a formula such as or if I 1 = I 2 = I, then Extend the first specification with the intersection of the second specification 20 and the negated first specification, where ¬ denotes negation and ^ denotes AND in the logic L,50. Thereafter, the method 100 may, but need not, include translating the extended data specification, i.e., the first specification 10 merged with this extension, to another abstraction level. This translation may be performed by abstraction and / or refinement. The method may further include generating at least one additional test for the technical system based on the extended data specification, in particular based on the refinement of the second part.

[0085] At least one additional test for the technical system may now be implemented, where additional time-related data is generated. The method 100 may include performing at least one additional test. The generated additional time-related data may, for example, be merged with the time-related data 1. Thereafter, the method 100 may be re-implemented. Alternatively, the method 100 may be implemented only based on the additional time-related data (as the time-related data 1 of the new implementation of the method 100).

[0086] Alternatively or additionally, the method 100 may be continued as follows:

[0087] The method 100 may include receiving additional time-related data (e.g., measurement and / or simulation data) from at least one additional test of the technical system.

[0088] The method 100 may further include translating the additional time-related data to another first specification in a first formal language at the first abstraction level. This may be performed, for example, via at least one abstraction.

[0089] The method 100 may further include defining another second specification in a second formal language at the second abstraction level based on the other first specification.

[0090] Furthermore, an iterative method is disclosed for automatically translating one or more specifications to at least one test for a technical system and determining the coverage of the specifications based on the results in the form of time-related data 1 (measurement and / or simulation data) of one or more tests of the technical system. This may be repeated until the specification is covered by one or more tests. For this purpose, let:

[0091] - s ∈ S j be a specification in the formal language S j that should be covered by one or more tests of the technical system,

[0092] - sel: S j × L → S j be a function that provides a partial specification such that

[0093] - To approach ⊥ in the proximity partial order (i.e., to approach or be at the lowest level of abstraction) from S j to the refinement sequence of the formal language S k of

[0094] - To be the abstraction sequence from S k to S j of

[0095] - s2e: S k → E is a function that transforms a specification s′ ∈ S into at least one test of a technical system, for example, by selecting parameters consistent with I(s′) k

[0096] - d2s: D → S k is a function that transforms the result in the form of time - related data (such as measurement data) d ∈ D of at least one test of a technical system into a specification s′ ∈ S k .

[0097] This iterative method can be mapped, for example, by the following algorithm:

[0098] K := false

[0099]

[0100] Let d be the time - related data 1 (such as measurement data) of at least one test of a technical system, s2e(s″)

[0101] s″′ := d2s(d)

[0102]

[0103] At least one test of the technical system violates the specification s or is too imprecise in abstraction. In this case, the method ends.

[0104] K := K v I(s″″)

[0105] In particular, the algorithm includes, at the latest in step receiving the second specification 20 (i.e., s) in the second formal language 20 at the second level of abstraction 130.

[0106] In addition, the algorithm includes, in the step "Let d be... time - related data 1", receiving 110 the time - related data 1 (i.e., d) from at least one test of a technical system.

[0107] In addition, the algorithm includes, in the steps "s″′ := d2s(d)" and ​includes translating time-related data 1 (i.e., d) 120 into a first specification 10 (i.e., s"") in a first formal language 11 at a first level of abstraction.

[0108] Furthermore, the algorithm in step includes checking 140, based on logical implication how the first specification 10 (i.e., s″″) and the second specification 20 (i.e., s) behave relative to each other. Here, in particular, based on logical implication checking: to what extent (more precisely whether or not) 142 the second specification 20 (i.e., s) covers the first specification 10 (i.e., s″″).

[0109] In this exemplary algorithm, the first specification 10 and the second specification 20 are defined in the same formal language, so both can be mapped into the logic 50 using the same interpretation mapping I. The iterative algorithm can also be adapted as follows: the first specification 10 and the second specification 20 are defined in different formal languages. Here, then, specific interpretation mappings (i.e., I 1 (s″″) and I 2 (s)) must be used separately.

[0110] The following example illustrates the application of the method 100 in the context of a vehicle with at least partial autonomous driving. In this example, the goal of the specification can be the formalization of the driving behavior of a vehicle with at least partial autonomous driving (ego vehicle or AV) in an intersection situation with another traffic participant (subject) as schematically presented in Figure 4 A part of the intersection forms the area G2, in which the ego vehicle and the subject can stay simultaneously, which, however, should be avoided. The driving intention of the ego vehicle can be, for example, to move along the sequence of areas Y, G1, G2, H, J. The driving intention of the subject can be, for example, to move along the sequence of areas M, G2, L, N.

[0111] Therefore, here, the technical system is a vehicle with at least partial autonomous driving (ego). For this application scenario, the logic 50 can be defined exemplarily as follows: the logic 50 can be a linear temporal logic.

[0112] The logic 50 can include the following propositional atoms: for the overlap of the (ego) vehicle with an area Z each area Z from the set of areas Y, G1, G2, H, J, in which the (ego) vehicle can move. These propositional atoms can then be represented by to.

[0113] Alternatively or additionally, the logic 50 can include the following propositional atoms: for the overlap of another traffic participant with an area Z Each region Z is from the set of regions M, G2, L, N, in which another traffic participant can move. These propositional atoms can then be represented by as follows.

[0114] Alternatively or additionally, the logic 50 can include the following propositional atoms: for the overlap of the prediction of the (ego) vehicle with another traffic participant at time step k of the prediction horizon where each k is from the set of time steps of the prediction horizon. These propositional atoms can then be represented by as follows.

[0115] Alternatively or additionally, the logic 50 can include the following propositional atoms: for the overlap of the prediction of the (ego) vehicle with a region Z at time step k of the prediction horizon where each region Z is from the set of regions and each k is from the set of time steps of the prediction horizon. These propositional atoms can then be represented by as follows.

[0116] Alternatively or additionally, the logic 50 can include the following propositional atoms: for the overlap of the prediction of another traffic participant with a region Z at time step k of the prediction horizon where each region Z is from the set of regions and each k is from the set of time steps of the prediction horizon. These propositional atoms can then be represented by as follows.

[0117] In particular, the logic 50 can include the propositional atoms named above:

[0118] -

[0119] -

[0120] -

[0121] - and

[0122] - (for all regions Z and discrete prediction time points k respectively).

[0123] The propositional atoms themselves can be evaluated equally time-discretely in real time by means of linear temporal logic.

[0124] A propositional atom (or each of these propositional atoms) can, for example, have a value range with two values. In particular, a propositional atom (or each of these propositional atoms) can be a Boolean value (e.g., with value ranges “false”, “true” or 0, 1). Alternatively, a propositional atom (or each of these propositional atoms) can be a quantitative measure, in particular a quantitative measure for the degree of fulfillment. For example, a propositional atom (or each of these propositional atoms) can take negative values (and e.g. zero) for “false” and positive values for “true”. Each propositional atom is an element of logic 50.

[0125] In this example, predictions are made about the behavior of all traffic participants relevant to the traffic situation within the (ego) vehicle. The dynamics can be handled in a time-discrete manner, and the prediction horizon can, for example, have a length N (number of future time steps) at each time step. Thus, there can be two time dimensions here: actual (discrete) time and (discrete) prediction time at each actual time point.

[0126] The propositional atoms can now be divided into two groups: The following propositional atoms can only relate to actual (discrete) time: and whereas the following propositional atoms can relate to (discrete) prediction time in addition to actual (discrete) time: and

[0127] The propositional atoms can be determined, for example, based on measurement data as follows:

[0128] 1. In a fixed (x, y) coordinate system, regions Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y} can be described as polygons on a specific geometry (map). The positions of the autonomous (ego) vehicle (AV) and other agents can be measured in this coordinate system at discrete time points t k and represented as (x ego (t k ), y ego (t k )) and (x subj (t k ), y subj (t k ). Thus, the first two propositional atoms that only relate to actual time can be calculated:

[0129]

[0130] where is the empty set and ∩ is the intersection operator of logic 50.

[0131] 2. Additional atoms are required for each discrete actual time point t k at discrete time steps t p，j over the defined prediction horizon to predict all allowed behaviors of the vehicle (AV, subject) for 1 ≤ j ≤ N. This prediction can be made in the (ego) vehicle (AV). This prediction can either be measured together or this prediction must be determined immediately based on the available measurement data (i.e., time-dependent data 1). The allowed behaviors can be described in the local (s,t) coordinate system with the help of a simple dynamics model. Here it can be assumed that the t coordinate (here there is no time constant, but a spatial coordinate transverse to the direction of movement) remains constant and the movement takes place only along the s coordinate:

[0132]

[0133] Furthermore, it can be assumed that the acceleration lies in the interval a min ≤ a(t) ≤ a max For the speed, on the one hand, it can be assumed that the speed does not become negative (i.e., it can be assumed that the vehicle does not drive backwards). On the other hand, it can be assumed that the vehicle adheres to the maximum allowed speed v max . Thus, at each discrete prediction time point t p，j the predicted position s results as an interval s min (t p，j ) ≤ s(t p，j ) ≤ s max (t p，j ), where

[0134]

[0135] Figure 6 Exemplarily, the acceleration, speed, and position intervals with respect to the prediction time are shown.

[0136] The calculation can be performed for each discrete actual time point t k . Accordingly, v 0 can represent the speed measured at the discrete actual time point t k in the local coordinate system and s 0 can represent the position measured at the discrete actual time point t k in the local coordinate system.

[0137] 3. The position interval calculated in the local coordinate system can be transformed into the global coordinate system. For this purpose, it can be assumed that the vehicle moves along a road or a lane on the road that can be described in the local (s,t) coordinate system. The t coordinate can be assumed to be constant here and extended over the entire lane width. The road type can be defined, for example, according to the ASAM OpenDrive standard. For the simplest road type, i.e., a straight road,Figure 8 Illustrates an exemplary transformation from a local coordinate system to a global coordinate system.

[0138] The transformation of the local position interval expressed in s coordinates and extended to the entire lane width (t = ±b / 2) can result in a polygon in the global coordinate system, which can be referred to as the RS (Reach Set), for example, see Figure 7 Z can represent the region described as a polygon in the global coordinate system.

[0139] Using the reach set RS(t k ), the propositional atoms can now be calculated accordingly:

[0140]

[0141] Against the background of this example, three exemplary formal languages are now disclosed. Let the language S in this example 1 , S 2 , S 3 be syntactically defined as follows in Backus-Naur form:

[0142] The first formal language S 1 which may, but does not have to be, the first formal language 11 in method 100 can be defined, for example, as follows:

[0143]

[0144] An exemplary simple specification in the first formal language S 1 can be, for example:

[0145]

[0146] where the specification follows from these terms being 1 (true). Conflicts can thus be avoided in a timely manner.

[0147] The second formal language S 2 which may, but does not have to be, the second formal language 21 in method 100 can be defined, for example, as follows, where the comma "," results in tuple formation:

[0148]

[0149] where

[0150]

[0151] and again

[0152]

[0153] May, but need not be, the third formal language S of the third formal language 31 in method 100 3 May be defined, for example, as follows:

[0154] S 3 ::=S 2

[0155] In this example, therefore, the second formal language S 2 and the third formal language S 3 May be syntactically the same. However, they will be semantically different.

[0156] Exemplary formal language S 1 May syntactically correspond to statement logic, where the index k of the atom may imply an order in actual time. Thus, for example May intuitively represent that the (ego) vehicle stays in area Y at a point in time and no longer stays in that area at a later point in time. S 1 The meaning in L may be formalized as follows. Given the term s ∈ S 1 , the term may be transformed into disjunctive normal form s 1 ∨s 2 ∨...,, where s i May be a positive or negative propositional atom EgoInZoneY(k), SubjektInZoneM(k), Conjunction of. Let s i，k Be the conjunction consisting of the propositional atoms with index k in s i . Thus, the interpretation mapping I from s to L 1 May be given by the following formula:

[0157] ◇(s 1,1 ∧◇(s 1,2 ∧...))∨◇(s 2,1 ∧◇(s 2,2 ∧...))∨...

[0158] Where the following substitutions may be defined for the propositional atoms in s i，k :

[0159]

[0160] EgoInZoneY(k) → UeEY

[0161] SubjektInZoneM(k) → UeSM

[0162]

[0163] An LTL formula can be understood as a set of abstract situation sequences, where ◇(s 1，1 ∧◇(s 1，2 ∧…)) can represent that it is satisfied at the actual time point s 1，1 and is satisfied at a later time point s 1，2 , and so on. Here, s i，k can be a statement logic formula composed of the propositional atoms of L. The index k in the language elements of S 1 can represent the abstract actual time point here, while the index k′ in the interpretation can refer to the predicted time point. In the LTL formula, there is no index related to the actual time here, because these relationships can be expressed through the temporal operators U (Until), ◇ (Eventually), and □ (Always). Only the relationships at the predicted time can be encoded through indices.

[0164] The languages S 2 and S 3 can be syntactically the same. The elements of the language (s 1，1 , s 1，2 ,...), (s 1，1 , s 2，2 ,...),... can describe the set of tuples (sequences) of conjunctions of propositional atoms, and these propositional atoms can occur positively (e.g., EgoInZoneY) or negatively (e.g., ).

[0165] The interpretation mapping I 2 from S 2 to L can be given by the following formula:

[0166] ◇(s 1,1 ∧◇(s 1,2 ∧...))∨◇(s 2,1 ∧◇(s 2,2 ∧...))∨...

[0167] where the following substitutions are defined for the propositional atoms in s i，k :

[0168]

[0169] EgolnZoneY(k)→UeEY

[0170]

[0171] SubjektInZoneM(k)→UeSM

[0172]

[0173] The index k here is the position of s i，k in the tuple.

[0174] From S 3 to the interpretation mapping I of L 3 can be given by the following formula:

[0175]

[0176] where for the propositional atom s i，k the same substitution can be applied as for S 2 Intuitively, I 2 can represent that each s in the specified order i，k must be true at all times. And in the case of I 3 it can be required that: each s i，k must always apply until the next element s i，k+1 becomes true. Thus, in particular, there cannot be a time point at which s is not satisfied i，k . This is perfectly possible in the case of I 2 .

[0177] If, for example, the refinement R 2，3 and the abstraction A 3，2 are given by identities, then and apply because the refinement R 1，2 can be defined by transforming s ∈ S 1 into disjunctive normal form, where the set of tuples is obtained by disjunction and the tuples themselves are obtained by conjunction. The reverse gives the abstraction A 2， 1. It should be noted here that to refine and delete all conjunctions that are However For this reason, abstract to with the corresponding k and delete in this abstraction Thus, in this example and apply.

[0178] Another exemplary specification in the first formal language S 1 can be given as follows:

[0179]

[0180] The refinement of this specification to S 2 or S 3 has the following form here:

[0181]

[0182] Alternatively or additionally, there is furthermore disclosed a computer-implemented method 200 for manufacturing a technical system according to a specification, in particular for manufacturing an at least partially autonomously driving vehicle or a part thereof according to a specification.

[0183] The method 200 may include receiving 210 a first specification 10 in a first formal language 11 at a first level of abstraction, wherein the first formal language 11 has a first semantics defined by a first interpretation mapping 12 from the first formal language 11 to a logic 50, wherein preferably the logic 50 is decidable.

[0184] The method 200 may furthermore include receiving 130 a second specification 20 in a second formal language 21 at a second level of abstraction, wherein the second formal language 21 has a second semantics defined by a second interpretation mapping 22 from the second formal language 21 to the logic 50.

[0185] The method 200 may furthermore include checking 240, based on logical implication (based on the logic 50): how the first specification 10 and the second specification 20 behave relative to each other, in particular based on logical implication checking: to what extent 241 (in particular whether) the first specification 10 covers the second specification 20 and / or to what extent 242 (in particular whether) the second specification 20 covers the first specification 10.

[0186] The method 200 may be the method 100 in all the embodiments disclosed therefor, except that in the method 200 the first specification is not necessarily translated 120 according to time-related data 1. In other words, the step 110 in the method 100 may not be necessary, and the step 120 may be adapted as follows: receiving 210 a first specification 10 in a first formal language 11 at a first level of abstraction.

[0187] There is furthermore disclosed a computer system which is designed to implement a computer-implemented method 100 for manufacturing a technical system according to a specification, in particular for manufacturing an at least partially autonomously driving vehicle or a part thereof according to a specification. The computer system may include a processor and / or a working memory.

[0188] There is furthermore disclosed a computer program which is designed to implement a computer-implemented method 100 for manufacturing a technical system according to a specification, in particular for manufacturing an at least partially autonomously driving vehicle or a part thereof according to a specification. The computer program may exist, for example, in an interpretable or compiled form. It may (also partially) be loaded, for example, as a sequence of bits or bytes into the RAM of a computer for implementation.

[0189] Furthermore, a computer-readable medium or signal is disclosed that stores and / or contains the computer program. The medium may include, for example, one of RAM, ROM, EPROM, HDD, SSD, etc., on which / in which the signal is stored.

Claims

1. A computer-implemented method (100) for producing a technical system according to specifications, in particular for producing an at least partially autonomously driven vehicle or a part thereof according to specifications, comprising: - receiving (110) time-related data (1) from at least one test of the technical system; - translating (120) the time-related data (1) into a first specification (10) in a first formal language (11) at a first level of abstraction, wherein the first formal language (11) has a first semantics defined by a first interpretation mapping (12) from the first formal language (11) to logic (50); - receiving (130) a second specification (20) in a second formal language (21) at a second level of abstraction, wherein said second formal language (21) has a second semantics defined by a second interpretation mapping (22) from said second formal language (21) to said logic (50); - based on a logical implication check (140): how the first specification (10) and the second specification (20) behave relative to each other, in particular based on the logical implication check: to what extent (141) the first specification (10) covers the second specification (20) and / or to what extent (142) the second specification (20) covers the first specification (10).

2. The method (100) of claim 1, wherein the first level of abstraction is the second level of abstraction; Optionally, the first formal language (11) is the second formal language (21).

3. The method (100) according to claim 1 or 2, wherein the logic (50) is a sequential logic, in particular a linear sequential logic or a signal sequential logic.

4. The method (100) according to any one of the preceding claims, wherein translating (120) the time-dependent data (1) into a first specification (10) in a first formal language (11) at a first level of abstraction comprises: - translating (121) the time-related data (1) into a third specification (30) in a third formal language (31) at a third level of abstraction, wherein the third formal language (31) has a third semantics defined by a third interpretation mapping (32) from the third formal language (31) to the logic (50); - translating (122) said third specification (30) into said first specification (10).

5. The method (100) of claim 4, wherein translating (122) the third specification (30) into the first specification (10) is an abstraction or a refinement.

6. The method (100) according to any one of the preceding claims, wherein receiving (130) a second specification (20) in a second formal language (21) at a second level of abstraction comprises: - receiving (131) a fourth specification (40) in a fourth formal language (41) at a fourth level of abstraction, wherein said fourth formal language (41) has fourth semantics defined by a fourth interpretation mapping (42) from said fourth formal language (41) to said logic (50); - translating (132) said fourth specification (40) into said second specification (20).

7. The method (100) of claim 6, wherein translating (132) the fourth specification (40) into the second specification is an abstraction or a refinement.

8. The method (100) according to any of the preceding claims, wherein it is checked (141) whether the first specification (10) covers the second specification (20); The approval of the technical system is premised on the first specification (10) covering the second specification (20).

9. The method (100) according to any of the preceding claims, wherein it is checked (142) whether the second specification (20) covers the first specification (10); The approval of the technical system is premised on the second specification (20) covering the first specification (10).

10. The method (100) according to any of the preceding claims, wherein it is checked (143) based on the logical implication whether a first part of the first specification (10) exceeds the second specification (20); Optionally, if such a first portion exists, the second specification (20) is extended by the intersection of the first specification (10) and the negated second specification.

11. The method (100) according to any of the preceding claims, wherein it is checked (144) based on the logical implication whether a second part of the second specification (20) exceeds the first specification (10); Optionally, if such a second part exists, at least one further test of the technical system is generated based on a refinement of the second part.

12. The method (100) according to claim 11, comprising: - receiving further time-related data from at least one further test of the technical system; - optionally via abstraction, translating said further time-related data into a further first specification in said first formal language at said first level of abstraction; - defining a further second specification in said second formal language at said second level of abstraction based on said further first specification.

13. The method (100) according to any of the preceding claims, wherein the technical system is an at least partially autonomously driven vehicle, wherein the logic (50) is a linear temporal logic comprising the following propositional atoms: - for the overlap of the vehicle with zone Z Each zone Z is from the set of zones in which the vehicle can move; - for the overlap of another road user with the zone Z Each zone Z is from the set of zones in which the other traffic participant can move; - for the overlap of the predictions of the vehicle and the other road user at time step k in the prediction horizon Each k is a set of time steps from the prediction horizon; - for the predicted overlap of the vehicle with the zone Z at time step k in the prediction horizon Each region Z is from the set of regions and each k is from the set of time steps of the prediction horizon; and for the overlap of the prediction of the other road user with the zone Z at time step k of the prediction horizon Each region Z comes from the set of regions and each k comes from the set of time steps in the prediction horizon.

14. A computer system designed to implement a computer-implemented method (100) for producing a technical system in accordance with specifications, in particular for producing an at least partially autonomously driven vehicle or a part thereof in accordance with specifications, according to any of the preceding claims.

15. A computer program designed to implement a computer-implemented method (100) for producing a technical system in accordance with specifications, in particular for producing an at least partially autonomously driven vehicle or a part thereof in accordance with specifications, according to any one of claims 1 to 13.

16. A computer readable medium or signal storing and / or containing a computer program according to claim 15.

Images