Specification-compliant technical system by means of formal language with common logic

Abstract

To provide a computer-implemented method for manufacturing a specification-compliant technical system, in particular a specification-compliant at least partially autonomous driving vehicle or a part thereof.SOLUTION: A method includes: receiving time-dependent data from at least one test of a technical system; translating the time-dependent data into a first specification in a first formal language at a first level of abstraction, the first formal language having a first semantics that is defined by a first interpretation mapping from the first formal language into a logic; receiving a second specification in a second formal language at a second level of abstraction, the second formal language having a second semantics defined by a second interpretation mapping from the second formal language into the logic; and checking, based on a logical implication, how the first specification and the second specification relate to each other.SELECTED DRAWING: Figure 1a

Description

Technical Field

[0001] Prior Art For example, in complex and safety-critical technical systems such as autonomous systems (e.g., autonomous driving, human-robot collaboration in industrial production, etc.), specifications are used for documentation, product development, and assurance (e.g., by means of test methods) and are part of the required release argumentation.

Background Art

[0002] In most cases, specifications are used in a top-down approach, i.e., starting from the specifications, a specific product (software and / or hardware) is developed. Development along the well-known V-model is an example established, for example, in the automotive industry, in terms of the refinement process in the development process from specifications to products, but not necessarily the refinement of the specifications themselves. Irrespective of the V-model, it may also be necessary and / or useful to represent multiple specifications at different levels of abstraction. In particular, it may be necessary and / or useful to refine specifications at a relatively high level of abstraction into specifications at a relatively low level of abstraction. At the same time, it may be necessary and / or useful to abstract (i.e., generalize) specifications at a relatively low level of abstraction into specifications at a relatively high level of abstraction.

[0003] In industrial practice, specifications are usually informally described in a requirements management tool such as IBM / DOORS, for example, in natural language. For this, some, usually manual, steps are required to ensure the consistency between the product and the specifications, but these steps cannot be formally guaranteed respectively. Automatic refinement and / or abstraction of specifications is not possible here.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Accordingly, the problem underlying the present disclosure is to provide automation for refining and / or abstracting one or more specifications.

[0005] For example, formal specification languages such as Z, B, and Event-B enable stepwise refinement of specifications in order to construct, by formal means (semi-automatically using a theorem prover or automatically using model checking), provable relationships between multiple specifications at different levels of abstraction. However, the above languages are not suitable for expressing specifications based on temporal logics such as LTL (Linear Temporal Logic). Further, in the case of the above formal specification languages, each specification still has to be manually formalized at different levels of abstraction, and only then can it be (automatically) checked, for example, whether those specifications are correct refinements or abstractions.

[0006] Accordingly, the problem underlying the present disclosure is further to automatically generate consistent specifications, particularly at least at one level of abstraction and especially at multiple different levels of abstraction. Accordingly, a hierarchy of specifications should be constructed.

[0007] Accordingly, a more comprehensive problem underlying the present disclosure is to manufacture a technical system according to the specifications. Means for Solving the Problem

[0008] Disclosure of the Invention The above problem is solved by the framework proposed in the present disclosure, which can represent or be able to represent a plurality of specifications by formal languages at different abstraction levels. The formal languages can each have one semantics based on a common logic. The framework proposed in this specification can create a plurality of specifications in different formal languages respectively, these formal languages can be syntactically expressed by a general term structure, and in that these formal languages are each semantically fixed by a common logic (for example, by temporal logic), it is already different from known methods. In the following, in most cases, for example, refinement or abstraction can be defined through this common logic, which is simply referred to as logic. Refinement or abstraction may be defined as converting from one formal language at a certain abstraction level to another formal language at a certain abstraction level. Refinement or abstraction may be computer-implemented and thus automatically implemented.

[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 a vehicle or a part thereof that runs at least partially autonomously according to the specification. The method includes receiving time-dependent data from at least one test of the technical system. The method further includes converting the time-dependent data into a first specification in a first formal language at a first level of abstraction, where the first formal language has a first semantics defined by a first interpretation mapping from the first formal language to logic. The logic may be decidable. The method further includes receiving a second specification in a second formal language at a second level of abstraction, where the second formal language has a second semantics defined by a second interpretation mapping from the second formal language to 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, for this purpose, the method may include checking 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 configured to implement a computer-implemented method according to the first general aspect (or an embodiment thereof) for manufacturing a technical system according to a specification, in particular for manufacturing a vehicle or a part thereof that runs at least partially autonomously according to the specification.

[0011] A third general aspect of the present disclosure relates to a computer program configured to implement a computer-implemented method according to the first general aspect (or an embodiment thereof) for manufacturing a technical system according to a specification, in particular for manufacturing a vehicle or a part thereof that runs at least partially autonomously according to the specification.

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

[0013] The specification (e.g., the first specification and / or the second specification, and thus each specification) may include, or be, a characterization of the system behavior over time. The system behavior may be the behavior of a technical system (in accordance with the specification). The specification may include one or more requirements for the system behavior over time. The specification may already be formalized in a formal language at a certain level of abstraction. Alternatively, the specification may be a natural language specification at a certain level of abstraction for the time being, and may then be converted into a formal language (at this level of abstraction). The conversion may include one or more refinements and / or one or more abstractions. Alternatively or additionally, the conversion may include converting time-dependent data from at least one test of the technical system.

[0014] The levels of abstraction may be arranged in a partial order of levels of abstraction. The partial order of levels of abstraction may include at least one relatively low level of abstraction and at least one relatively high level of abstraction. The levels of abstraction and, optionally, the arrangement of the levels of abstraction in the partial order may be defined by expert knowledge. The levels of abstraction can become lower the more detailed they are in at least one test of the technical system.

[0015] A formal language, unlike a natural language, can be an abstract language in which (in many cases) the focus is not on communication but on defining and applying a formal system in a narrow sense and logic in a broad general sense. A formal language consists of a set of specific character strings, which can be referred to as the words of the language and can be composed from an alphabet (also called a letter set). The alphabet does not necessarily have to be the well-known alphabet (such as a, b, c, etc.) in linguistics. A formal language with respect to an alphabet may be regarded as a subset of the Kleene closure of the alphabet. In addition to such a syntax, a semantics of the formal language can be defined.

[0016] Refining and / or abstracting one or more specifications forms a core aspect of the framework presented herein. Through framework instantiation and formal proof of correctness, it is possible to automate the implementation of one or more refinements and / or one or more abstractions.

[0017] In addition to a top-down approach (in view of the abstraction level), the framework enables an automated bottom-up approach (similarly in view of the abstraction level), i.e., the framework can generate, for example, the observed system behavior in the form of on-site measurements into abstract behavior. Such a set of abstract behaviors may be understood as a specification, as in the case of a method according to a first general aspect (or an embodiment thereof). A special case of this generalization may be the abstract scenario identification of driving data. A further example in this context may be the reconstruction of driving scenarios in a simulation environment.

[0018] The frameworks proposed in this specification, particularly the methods according to the first general aspect (or embodiments thereof), enable the consistent formalization of multiple specifications at different levels of abstraction. This makes it easier for specification developers to quickly and accurately formalize requirements at each level of abstraction. The automatic and consistent conversion to other levels of abstraction provides feedback to the specification developers, which facilitates the verification of the formalized specifications.

[0019] From manually formalized and automatically generated specifications, for example, one or more quantitative monitors can be generated, and these quantitative monitors can be used to automatically generate tests by an optimization method. In that case, this enables, for example, the (informal) proof of desired properties in a product.

[0020] Using one (generally) unique formal language for each level of abstraction, or rather, using multiple formal languages at one level of abstraction, is carried out based on a generic term structure. Each language may be understood as a DSL (Domain Specific Language) that enables effectively formalizing the core of each level of abstraction. Frameworks for abstraction and / or refinement can reduce the cost for ensuring consistency between specifications and products / implementations. Thus, for example, the corresponding part of software can be directly generated from specifications at an appropriate level of abstraction. For example, software for an automated vehicle's behavior planner can be generated from the specifications of the behavior of a vehicle with at least partial automation or a monitoring monitor that identifies possible future situations that may pose problems. Furthermore, a framework for abstraction and / or refinement, particularly by a method according to a first general aspect (or an embodiment thereof), enables presenting recorded field data (e.g., driving situation data) in the form of "equations" at various different levels of abstraction that are understandable to specification developers. Thereby, on the one hand, a wide range of sets of time-dependent data (also referred to as field data (e.g., driving data)) from at least one test of a technical system can be associated with multiple equivalence classes regarding different levels of abstraction. On the other hand, the data can be more easily interpreted regarding its expressiveness. Thereby, missing specifications can be identified. In this case, for example, the following cases can be distinguished: cases that are included in the data but have not been formalized in the specifications so far, cases where the specifications are not satisfied (specifications formalized in the form of "if-then rules" where the data violates the "then"), and cases where the field data is incomplete (specifications in the form of "if-then rules" where the data does not cover the "if").

[0021] These features enable the design of an apparatus for testing complex technical systems (e.g., a vehicle or a part thereof that drives at least partially autonomously) with the goal of efficiently using test costs (e.g., test drives) with respect to the coverage of a given set of specifications / requirements. For this purpose, for example, in an iterative process, first, it is possible to identify as few tests as possible (e.g., driving maneuvers) of the technical system that cover all manually formalized and automatically generated specifications at different abstraction levels. For this purpose, for example, an initial set of one or more tests of the technical system can be constructed using an appropriate DOE (Design of Experiments) method. For each test, after the execution of those tests, the results by abstraction at all abstraction levels (i.e., measurements and / or simulations) can be automatically represented. If such an abstraction of a measurement (in the method according to the first general aspect (or an embodiment thereof), for example, the first specification) is consistent with the specification to be covered (in the method according to the first general aspect (or an embodiment thereof), for example, the second specification), then this abstraction of the measurement meets the specification. Thus, a framework for abstraction and / or refinement enables an automatic check of multiple specifications at different abstraction levels based on tests. If the abstraction of a test meets the specification, then this specification can be considered to be covered by the test in the simplest case. Furthermore, since the test is represented by an abstraction in the formal language of the specification (in the method according to the first general aspect (or an embodiment thereof), in the first formal language), it can be considered more precisely. Thus, for example, it is possible to check whether the abstraction completely covers the specification or only partially covers it. In the latter case, if necessary or desired, for example, at least one further test of the technical system can be automatically generated by refining the part of the specification that is not covered by the abstraction of the test.On the other hand, when the test abstraction conflicts with the specification, it is possible to distinguish whether it is truly an error in the product, whether the specification contains an error, or whether there is an apparent conflict due to the test abstraction, and it is possible to confirm it in particular.

[0022] The method according to the first aspect (or its embodiment) proposed in the present disclosure enables, for example, the development of a specification in an iterative process, and this iterative process can benefit from formal refinement relationships and abstraction relationships. For this purpose, for example, the observation results of a specific technical system in the form of field data (time-dependent data) can also contribute exactly. When put in an appropriate form, these field data may be understood as elements of a refined specification language (a language close to ⊥ in a semi-order, that is, a language at a lower abstraction level). Through abstraction, the representation can be automatically converted into multiple formal languages, and these formal languages are realizable in a semi-order by abstraction. Each of these data specifications d can be associated with a specification s created manually or automatically generated by refinement or abstraction. In this case, by checking how the first specification and the second specification behave with respect to each other, for example, the following results can be obtained.

[0023] For example, the fact that the second specification s (that is, for example, a pre-set specification) covers the first specification d (that is, the data specification), that is,

Number

[0024] Alternatively or additionally, that the first specification d (i.e., the data specification) covers the second specification s (i.e., a pre-set specification, for example), i.e., [Number] if it is found that it is, the pre-set specification is covered by the abstraction of the data. If this is not the case, in order to generate the missing data, by automatically refining I(s) ∧ ¬I(d) in the direction of the formal language close to ⊥ in the semi-order, further tests of one or more technical systems can be found.

[0025] The method according to the first general aspect (or an embodiment thereof) may include performing one or more of these further tests. [Brief Description of the Drawings]

[0026]

Figure 1a

Figure 1b

Figure 1c

Figure 1d

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

[0027] Detailed Description The advantages described are achieved by providing various different formal languages based on a generic term structure that enables representing multiple specifications at different abstraction levels. These formal languages are based on a semantics, i.e., a common logic that defines the meaning of these formal languages. The specification of one formal language can be automatically converted into a consistent specification in another formal language. In this case, two directions, namely, abstraction and refinement, are distinguished.

[0028] Figure 5 illustratively and schematically shows a plurality of abstraction levels (rounded boxes), where, in this case, the higher the abstraction level is illustrated above Figure 5, the higher it is in view of the degree of abstraction of that abstraction level. For each abstraction level, at least one formal language can be defined. An exemplary association between a first formal language 11 and a third formal language 31 is also shown. Thus, Figure 5 can show, for example, a formal language for the specification of relevant traffic situations and scenarios (sequences of fixedly defined traffic situations) in the context of at least partially autonomous driving. The formal languages can form a semi-order with respect to refinement. The relationship S j →S k for S j any valid specification in the language can be changed to a corresponding refined specification in the S k language. When changing the specification in the opposite direction of this arrow, it is called abstraction. It should be noted that for each refinement, there does not necessarily have to be an abstraction, and vice versa.

[0029] The framework for abstraction and / or refinement may be described by a plurality of formal languages S 1 , ···, S n (at least two formal languages), and between two formal languages S j , S k there may exist an abstraction relationship or a refinement relationship. The formal language S j is understood as a set of terms realized syntactically by the following simple rules (e.g., in Backus-Naur form)

Number

[0030] In this case, the set of admissible terms of the formal language can be restricted syntactically or by a type system. The syntactic structure may be defined, for example, by a framework such as Xtext, a metaprogramming language such as Racket, or a theorem prover such as Lean4.

[0031] Formal language S j The valid term t ∈ S j (also referred to as a well-formed term) acquires its meaning by an interpretation mapping I j To be able to define such an interpretation mapping, first, a semantic basis for all languages S 1 , ···, S n among a plurality of formal languages is specified. Forming this semantics is to specify a particular logic L. This logic L is also referred to as a common logic. As the logic L, for example, a temporal logic such as linear temporal logic (LTL) or signal temporal logic is considered. Alternatively or additionally, the temporal logic can also be combined with an arithmetic theory such as linear arithmetic, real arithmetic, or real polynomial arithmetic. In this way, for example, the change of geometric objects over time can be described. Syntactically, the logic may also be understood as a set of terms in the same way.

[0032] (in particular any) formal language S j For, the interpretation mapping I j from the formal language S j : S j → L to the logic L can be inductively defined through the term structure of S j whose semantics is specified by the logic L. That is, the interpretation mapping I j converts each term s ∈ S j into a term l = I j (s) ∈ L of the logic L. The term l = I j (s) ∈ L for s ∈ S jcan be called an interpretation. A logical term is also a statement at the same time. In this case, for the automation possibility of the abstraction framework / refinement framework, it is advantageous for the logic L to be decidable. That is, when two terms (also called statements) l 1 , l 2 ∈L are given, whether the statement l 1 logically implies the statement l 2 , that is, whether the logical implication

Number

Number

Number

Number

Number

Number

Number

Number

[0033] Formal language S k is exactly

Number

Number

[0034] Formal language S j is exactly

Number

Number

[0035] Language S 1 , ···, S n can form one partial order each with respect to the relation

Number

Number

Number

Number

Number

Number

[0036] The accuracy of each refinement or abstraction relationship can be formally shown, for example, using a theorem prover, by induction through each term structure. In this case, logical implication

Number

[0037] Here, a computer - implemented method 100 schematically shown in FIGS. 1a to 1d for manufacturing a technical system according to a specification is disclosed. The computer - implemented method 100 may be, in particular, a method for manufacturing at least a partially autonomous vehicle or a part thereof according to a specification. The technical system may be a cyber - physical system. The technical system may be at least a partially autonomous system. For example, the technical system may be at least a partially autonomous vehicle or a part thereof.

[0038] The method 100 includes receiving 110 time - dependent data 1 from at least one test of a technical system. The time - dependent data 1 may include, for example, measurement data and / or simulation data, or may be measurement data and / or simulation data.

[0039] Method 100 is the conversion 120 of time-dependent data 1 into a first specification 10 in a first formal language 11 at a first level of abstraction, the first formal language 11 having a first semantics defined by a first interpretation mapping 12 from the first formal language 11 to a logic 50, the logic 50 being preferably decidable. The first specification 10 can be referred to as a data specification. The first level of abstraction may be, for example, a lower or lowest level of abstraction (with respect to the semi-order of abstraction). On the other hand, the first level of abstraction may also be a higher or highest level of abstraction (with respect to the semi-order of abstraction). FIG. 2 schematically shows the association where the first level of abstraction is not located at the two lowest levels of abstraction. The adjective "first" in "the first level of abstraction" does not necessarily represent the first element in the semi-order of abstraction and / or refinement. In other words, each level of abstraction in such a semi-order may be the first level of abstraction in the sense of step 120.

[0040] Method 100 comprises receiving 130 a second specification 20 in a second formal language 21 at a second level of abstraction, the second formal language 21 having a second semantics defined by a second interpretation mapping 22 from the second formal language 21 to logic 50. The second specification 20 may be a pre-set specification. A specification can be considered a pre-set specification if it is provided at least when the (respective) method step (here step 140) in which the specification is processed is performed, particularly if it is provided for each (respective) method step. Thus, unlike what is schematically shown in FIGS. 1a to 1d, step 130 may be performed before step 120, or may be performed together with step 110, or may be performed before step 110. In particular, the second specification 20 need not be converted from time-dependent data 1 from step 110. The second level of abstraction may be, for example, a higher or topmost level of abstraction (with respect to the semi-order of abstraction). On the other hand, the second level of abstraction may be a lower or bottommost level of abstraction (with respect to the semi-order of abstraction). Again, FIG. 2 schematically shows the association where the second level of abstraction is located at a certain level of abstraction. Here too, the adjective "second" in "second level of abstraction" does not necessarily represent the second element in the semi-order of abstraction and / or refinement. In other words, each level of abstraction of such a semi-order may be the second level of abstraction in the sense of step 130.

[0041] The first specification and / or the second specification may each be a characterization of system behavior over time (i.e., the behavior of a technical system). The first specification may be an actual specification. The second specification may be a target specification.

[0042] Method 100 comprises logical implication

Number

Number

[0043] In other words, method 100 involves logical implication

Number

Number

Number

[0044] As already discussed in the context of general frameworks for refinement and / or abstraction, a formal language may be considered to include a set of terms, or to be a set of terms, especially from a syntactic point of view. One or more rules can be applied to this set of terms. That is, only the terms that satisfy the one or more rules become components of the formal language and thus valid terms. A formal language may have a semantics defined by an interpretation mapping from the formal language to logic. At least two formal languages (especially a formal language among a plurality of formal languages) may each have one semantics, and each semantics is defined by its (i.e., generally unique) interpretation mapping from its formal language to logic. This is schematically shown in FIG. 3. The evaluation of the interpretation mapping in the terms of a formal language can be referred to as the interpretation of the terms. Logic can be regarded as a basis for describing the semantics for each language. Thanks to logic, the expressions of a plurality of different formal languages can be associated with each other. Thereby, it is possible to check 140 how the first specification 10 and the second specification 20 behave with respect to each other.

[0045] A specification A (e.g., the first specification 10) in one formal language (e.g., the first formal language 11) covers a specification B (e.g., the second specification 20) in another formal language (which may be, for example, the second formal language 21 but may also be the first formal language) when the interpretation of this specification B (e.g., I 2 (B)) implies the interpretation of specification A (e.g., I 1 (A)), that is,

Number

[0046] For example, the first specification d (data specification) exactly

Number

Number

Number

[0047] As already discussed in the context of a general framework, a statement l 1 of the logic L can, for example, be formally derived from a statement l 1 to a statement l 2 using a deductive system consisting of the axioms and derivation rules of the logic L. When this is possible, the statement l 2 of the logic L can imply the statement l

Number

[0048] Logical implication

Number

[0049] The first level of abstraction may be the second level of abstraction, but does not necessarily have to be the second level of abstraction. In the exemplary FIG. 2, the second level of abstraction is lower than the first level of abstraction (with respect to the semi - order of abstraction). However, the second level of abstraction may be higher than the first level of abstraction (with respect to the semi - order of abstraction) or, rather, may be at the same level of abstraction, different from what is schematically shown in FIG. 2.

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

[0051] If the first formal language is the second formal language, the first semantics may be regarded as the second semantics. In this case, the first interpretation mapping is also the second interpretation mapping. On the other hand, if the first formal language and the second formal language are different, the first semantics and the second semantics may be different (and usually are). In this case, the first interpretation mapping and the second interpretation mapping are different.

[0052] The logic L,50, i.e., the common logic, may be a temporal logic. In particular, the logic may be a linear temporal logic (also referred to as LTL) or a signal temporal logic.

[0053] Alternatively or additionally, the logic may include one or more (decidable) fragments of predicate logic. In particular, the logic may include one or more decidable fragments of predicate logic, such that the decidability can be regarded as arising from a decidable "satisfiability modulo theories" problem, and / or may include a combination of a temporal logic and at least one such fragment of predicate logic.

[0054] It is advantageous for the logic to be decidable. On the other hand, as long as at least the representation of the logic is decidable, i.e., the logical implication (regarding the logic) is decidable, it is still possible to implement method 100.

[0055] As schematically shown in FIGS. 1b and 1d, the conversion 120 of the time-dependent data 1 into the first specification 10 in the first formal language 11 at the first abstraction level may first involve converting the time-dependent data 1 into a third specification 30 in a third formal language 31 at a third abstraction level, where 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. This may include 121. Subsequently, it may include 122 the conversion of the third specification 30 into the first specification 10.

[0056] The third level of abstraction may be, for example, the lowest level of abstraction (with respect to the partial order of abstraction) as schematically shown in FIG. 2, or may be a lower level of abstraction (with respect to the partial order of abstraction). On the other hand, the third level of abstraction may here be any level of abstraction in the partial order of abstraction and / or refinement. Converting the third specification 30 to the first specification 10 at 122 may be an abstraction or a refinement, as schematically shown in FIG. 2.

[0057] Method 100 may include chaining a plurality (e.g., more than 2, more than 3, more than 4, more than 5, more than 10, more than 50) of steps of converting 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 chaining may include one or more abstractions. Alternatively or additionally, the chaining may include one or more refinements. For example, the chaining may include one or more abstractions and one or more refinements. For example, it is possible to first abstract the third specification 30 to a specification at an abstraction level higher than the first level of abstraction and then refine it to the first specification 10 at the first level of abstraction.

[0058] Alternatively or additionally, for example, as schematically shown in FIGS. 1c and 1d, receiving a second specification 20 in a second formal language 21 at a second level of abstraction at 130 may first be receiving a fourth specification 40 in a fourth formal language 41 at a fourth level of abstraction [Explanation: e.g., at 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 a logic 50, at 131. Thereafter, it may include converting the fourth specification 40 to the second specification 20 at 132.

[0059] The fourth level of abstraction may be, for example, the highest level of abstraction (with respect to the partial order of abstraction) as schematically shown in FIG. 2, or may be a higher level of abstraction (with respect to the partial order of abstraction). On the other hand, the fourth level of abstraction may here also be any level of abstraction in the partial order of abstraction and / or refinement. The conversion 132 of the fourth specification 40 to the second specification 20 may be an abstraction or, as schematically shown in FIG. 2, a refinement.

[0060] The fourth specification 40 may be the same as the second specification 20, but does not necessarily have to be a pre-set specification. If a specification is provided at least by the time when the (respective) method steps (here step 132) in which this specification is processed are carried out, in particular if it is provided for each (respective) method step, then that specification can be considered a pre-set specification. In particular, the fourth specification 40 does not have to be converted from the time-dependent data 1 from step 110.

[0061] The method 100 may include chaining a further plurality (e.g., more than 2, more than 3, more than 4, more than 5, more than 10, more than 50) of steps for converting the fourth specification 40 in the fourth formal language 41 at the fourth level of abstraction to the second specification 20 in the second formal language 21 at the second level of abstraction. The further chaining may include one or more refinements. Alternatively or additionally, the chaining may include one or more abstractions. For example, the chaining may include one or more refinements and one or more abstractions. For example, it is possible to first refine the fourth specification 40 to a specification at an abstraction level lower than the second level of abstraction and then abstract it to the second specification 20 at the second level of abstraction.

[0062] As schematically shown in FIG. 1d, the method 100 may include both the conversion 122 of the third specification 30 to the first specification 10 and the conversion 132 of the fourth specification 40 to the second specification 20.

[0063] Thus, in method 100 proposed in the present disclosure, two specifications (the first specification 10 and the second specification 20), in the same formal language or in different formal languages respectively, can be associated with (e.g., compared with) each other thanks to a common logic, and at least one of these two specifications (i.e., the first specification 10) is converted from time-dependent data 110, and these two specifications are, in some cases, converted from other specifications via a chain and / or a further chain.

[0064] In the following, one or more possible checks are disclosed, and these checks may be performed within the scope of checking 140, for example, as schematically shown in FIGS. 1a to 1d, but not necessarily so.

[0065] In method 100, for example, it is possible to check 141 whether the first specification 10 (i.e., the data specification d) covers the second specification 20 (i.e., for example, the pre-set specification s). That is, here

Number

Number

[0066] Alternatively or additionally, in method 100, it is possible to check 142 whether the second specification 20 (i.e., for example, a pre-set specification s) covers the first specification 10 (i.e., the data specification d). That is, here,

Number

Number

[0067] The release of the technical system can be based on both the second specification covering the first specification and the first specification covering the second specification. In this case, method 100 includes both checks. These conditions may be regarded as sufficient conditions, but they do not necessarily have to be so.

[0068] Alternatively or additionally, in method 100, logical implication

Number

[0069] If such a first part exists, the method 100 may include extending the second specification by an amount corresponding to the cut consisting of the first specification 10 and the negated second specification. In formula, for example, I 1 (d) ∧ ¬I 2 (s), or I 1 = I 2 = I 2 In the case of, it is I(d) ∧ ¬I(s), where ¬ represents negation and ∧ represents "and" in logic L,50. The method 100 may include converting the extended specification, i.e., the second specification 20 combined with the above extension, to another abstraction level. This conversion may be carried out by abstraction and / or refinement. The method 100 may include checking whether it is possible to extend the second specification by the amount of the cut. In particular, the method 100 may depend on the consent of the user of the method 100 (e.g., via a user interface) to extend the second specification. For example, it is also conceivable to intentionally exclude extending the second specification.

[0070] Alternatively or additionally, especially if the second specification does not cover the first specification, it is possible to check whether there is an error in the technical system, whether the second specification (or the fourth specification) contains an error, and / or whether there is an apparent contradiction by converting (especially abstracting) time-dependent data from at least one test of the technical system.

[0071] Alternatively or additionally, in method 100, logical implication

Number

[0072] If such a second part exists, method 100 may include extending the first specification by the amount of the cut consisting of the second specification 20 and the negated first specification. In formula, for example, I 2 (s) ∧ ¬I 1 (d) or I 1 = I 2When it is =I, it is I(s) ∧ ¬I(d), where ¬ represents negation and ∧ represents "and" in logic L,50. Then, method 100 may include, but does not necessarily have to include, converting the extended data specification, i.e., the first specification 10 combined with the above extension, to another abstraction level. This conversion may be carried out by abstraction and / or refinement. The method may further include generating at least one further test of the technical system based on the extended data specification, particularly based on the refinement of this second part.

[0073] Here, at least one further test of the technical system can be carried out, and as a result, further time-dependent data is obtained. Method 100 may include carrying out at least one further test. The further time-dependent data obtained as a result can be combined with, for example, time-dependent data 1. Then, method 100 can be carried out again. Alternatively, method 100 may be carried out only on the further time-dependent data (as time-dependent data 1 for the re-implementation of method 100).

[0074] Alternatively or additionally, method 100 can be continued as follows.

[0075] Method 100 may include receiving further time-dependent data (such as measurement data and / or simulation data) from at least one further test of the technical system.

[0076] Method 100 may further include converting the further time-dependent data to a further first specification in a first formal language at the first abstraction level. This may be carried out, for example, through at least one abstraction.

[0077] Method 100 may further include defining a further second specification in a second language at the second abstraction level based on the further first specification.

[0078] One or more specifications are automatically converted into at least one test of a technical system, and an iterative method for identifying the coverage of a specification from the results of one or more tests of the technical system in the form of time-dependent data 1 (measurement data and / or simulation data) is further disclosed. This can be repeated while the specification is covered by one or more tests. In this regard, · s ∈ S j is a specification in the formal language S j to be covered by one or more tests of the technical system, · sel: S j × L → S j is

Number

Number

Number

[0079] This iterative method can be represented by, for example, the following algorithm.

Table 1

[0080] In particular, this algorithm includes receiving, at least at

Number

[0081] This algorithm further includes receiving, at the step of "let d be time-dependent data 1", time-dependent data 1 (i.e., d) from at least one test of the technical system, which is 110.

[0082] This algorithm

Number

Number

[0083] This algorithm

Number

Number

Number

[0084] In this exemplary algorithm, the first specification 10 and the second specification 20 are defined in the same formal language, and thus these two specifications can be mapped to logic 50 using the same interpretation mapping I. The iterative algorithm may be adjusted as if the first specification 10 and the second specification 20 were defined in different formal languages respectively. In that case, here, respective unique interpretation mappings (i.e., I 1 (s’’’’) and I 2 (s)) must be used.

[0085] The following example shows the application of a method 100 in the context of a vehicle that travels at least partially autonomously. The purpose of the specification in this example may be to formalize the driving behavior in a situation where a vehicle (the host vehicle or an AV) that travels at least partially autonomously and a further road user (an object) intersect. A part of the intersection forms a zone G2 where the host vehicle and the object may stay simultaneously, but this possibility should be avoided. The driving intention of the host vehicle may be, for example, to move along the zone sequence Y, G1, G2, H, J. The driving intention of the object may be, for example, to move along the zone sequence M, G2, L, N.

[0086] Therefore, here, the technical system is a (self-) vehicle that drives at least partially autonomously. In the case of this application scenario, logic 50 can be defined exemplarily as follows. That is, logic 50 may be a linear temporal logic.

[0087] Logic 50 may include, for each zone Z from the set of zones Y, G1, G2, H, J where the (self-) vehicle is movable, UeberschneidungEgoZoneZ regarding the overlap between the (self-) vehicle and zone Z. In the following, these propositional atoms can be represented as UeEZ = EZ = UeberschneidungEgoZoneZ, Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y}.

[0088] Alternatively or additionally, logic 50 may include, for each zone Z from the set of zones M, G2, L, N where additional road users are movable, UeberschneidungSubjektZoneZ regarding the overlap between the additional road users and zone Z. In the following, these propositional atoms can be represented as UeSZ = UeberschneidungSubjektZoneZ, Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y}.

[0089] Alternatively or additionally, logic 50 may include, for each time step k from the set of time steps of the prediction range, PraedizierteUeberschneidungEgoSubjekt_k regarding the predicted overlap between the (self-) vehicle and additional road users at time step k of the prediction range. In the following, these propositional atoms can be k =PraedizierteUeberschneidungEgoSubjekt k represented as PUeES, 1 ≤ k ≤ N.

[0090] Alternatively or additionally, the logic 50 may include, for each zone Z from the set of zones and for each time step k from the set of time steps of the prediction range, a PraedizierteUeberschneidungEgoZoneZ_k regarding the predicted overlap between the (ego) vehicle and zone Z at the time step k of the prediction range. These propositional atoms will be referred to as PUeEZ hereinafter. k =PraedizierteUeberschneidungEgoZoneZ k , which can be represented as 1 ≦ k ≦ N, Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y}.

[0091] Alternatively or additionally, the logic 50 may include, for each zone Z from the set of zones and for each time step k from the set of time steps of the prediction range, a PraedizierteUeberschneidungSubjektZoneZ_k regarding the predicted overlap between a further road user and zone Z at the time step k of the prediction range. These propositional atoms will be referred to as PUeSZ hereinafter. k =PraedizierteUeberschneidungSubjektZoneZ k , which can be represented as 1 ≦ k ≦ N, Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y}.

[0092] In particular, the logic 50 may include the above propositional atoms, namely, ·UeberschneidungEgoZoneZ, ·UeberschneidungSubjektZoneZ, ·PraedizierteUeberschneidungEgoSubjekt_k, ·PraedizierteUeberschneidungEgoZoneZ_k, and ·PraedizierteUeberschneidungSubjektZoneZ_k for each zone Z and discrete prediction time point k (respectively).

[0093] The propositional atoms themselves can also be evaluated discretely over time using linear temporal logic over real time.

[0094] The propositional atoms (or each of these propositional atoms) can have, for example, a value range with two values. In particular, the propositional atoms (or each of these propositional atoms) may be taken as being boolean values (having, for example, the value ranges “false”, “true” or 0, 1). Alternatively, the propositional atoms (or each of these propositional atoms) may be taken as being a quantitative measure, in particular a quantitative measure regarding sufficiency. For example, the propositional atoms (or each of these propositional atoms) can take on negative values (and for example 0) in the case of “false” and positive values in the case of “true”. Each propositional atom is one element of the logic 50.

[0095] In this example, it is referred to predicting the behavior of all road users related to the traffic situation inside the (ego) vehicle. The dynamics can be processed discretely over time and the prediction range can have, for example, a length N (the number of time steps towards the future) at each time step. Thus, here it may be assumed that there are two time dimensions, namely the real (discrete) time and the (discrete) prediction time at each real time point.

[0096] Here, the propositional atoms can be divided into two groups. The following propositional atoms, namely UeberschneidungEgoZoneZ, Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y} and UeberschneidungSubjektZoneZ can be related only to the real (discrete) time. In contrast, the following propositional atoms, namely PraedizierteUeberschneidungEgoSubjekt k and PraedizierteUeberschneidungEgoZoneZ k and PraedizierteUeberschneidungSubjektZoneZ kIt can be related to (discrete) prediction time in addition to the actual (discrete) time.

[0097] Propositional atoms can be identified from measurement data, for example, as follows.

[0098] 1. In a fixed-position (x, y) coordinate system, zones Z ∈ {G1, G2, H, J, K, L, M, N, Q, Y} on a specific geometry (map) can be described as polygons. The position of an autonomous (self) vehicle (AV) and the positions of other objects can be measured at discrete time points t k in this coordinate system, and can be denoted as (x ego (t k ), y ego (t k )) or (x subj (t k ), y subj (t k ). Thus, the first two propositional atoms related only to the actual time can be

Number

Number

[0099] 2. Further atoms, for each discrete actual time point t k , for each discrete time step t p,j, it is necessary to predict all the allowable behaviors of the vehicle (AV, object) over the defined prediction range for 1≤j≤N. This prediction may be performed inside the (self-) vehicle (AV). This prediction may be performed together with measurements, or may have to be subsequently identified from existing measurement data (i.e., time-dependent data 1). The allowable behaviors can be described in the local (s,t) coordinate system using a simple dynamics model. In this case, the t coordinate (here, not the time constant but the spatial coordinate transverse to the moving direction) remains constant and the movement is performed only along the s coordinate: [Number] can be assumed.

[0100] Furthermore, the acceleration is in the range a min ≤a(t)≤a max can be assumed. On the one hand, regarding the speed, it can be assumed that the speed is non-negative (i.e., it can be assumed that the vehicle does not reverse). On the other hand, it can be assumed that the vehicle complies with the maximum allowable speed v max . Therefore, the predicted position s at each discrete prediction time t p,j is obtained as the interval s min (t p,j )≤s(t p,j )≤s max (t p,j ), where [Number] is.

[0101] Figure 6 exemplarily shows the acceleration interval, speed interval, and position interval over the prediction time.

[0102] The calculation may be performed for each discrete actual time t k . Accordingly, v 0 is the discrete actual time t in the local coordinate system kcan indicate the speed measured at s 0 k can indicate the position measured at the discrete actual time point t in the local coordinate system.

[0103] 3. The calculated position intervals in the local coordinate system can be converted to the global coordinate system. For this purpose, it can be assumed that the vehicle moves along a road that can be described in the local (s, t) coordinate system or along a lane on this road. In this case, the t coordinate can be expanded to the entire lane width assuming it is constant. The road type may be defined, for example, in accordance with the ASAM's OpenDrive standard. Figure 8 shows an exemplary conversion from the local coordinate system to the global coordinate system for the simplest road type, i.e., a straight road.

[0104] By converting the local position intervals expressed in the s coordinate and expanded to the entire lane width (t = ±b / 2), a polygon in the global coordinate system can be obtained as a result, and this polygon can be referred to as RS (reach set). For this, see, for example, Figure 7. Z can represent the zone described as a polygon in the global coordinate system.

[0105] Here, using the reach set at each prediction time point RS(t k ), the propositional atoms can be calculated accordingly as

Number

[0106] Here, in the context of this example, three exemplary formal languages are disclosed. Languages S 1 , S 2 , S 3 shall be defined syntactically in Backus-Naur form as follows in this example.

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

Number

Number

Number

[0108] The second formal language S, which may be the second formal language 21 in method 100, but does not necessarily have to be 2 can be defined, for example, as

Number

Number

Number

[0109] The third formal language S, which may be the third formal language 31 in method 100, but does not necessarily have to be 3 can be defined, for example, as

Number

[0110] An exemplary formal language S 1 can correspond syntactically to propositional logic, and the subscript k of an atom can imply an order in real time. Thus, for example, EgoInZoneY(1) ∧ ¬EgoInZoneY(2) can intuitively mean that the (self) vehicle is staying within zone Y at a certain point in time and is no longer staying within zone Y at a later point in time. The meaning of S in L 1 may be formalized as follows. Given a term s ∈ S 1 , this term can be transformed into a disjunctive normal form s 1 ∨s 2 ∨ ···, where S i may be a conjunction of positive or negative propositional atoms PredizierteKollisionEgoSubjekt(k), EgoInZoneY(k), SubjektInZoneM(k), PreadiziertEgoSubjektInZoneG1G2(k). Let s i,k be a conjunction consisting of propositional atoms in S i with subscript k. Thereby, the interpretation mapping I of s in L 1 can be given by the following formula:

Number

Number

[0111] An LTL formula can be understood as a set of sequences of abstract situations, where

Number

Number

[0112] The languages S 2 and S 3 may be syntactically identical. The elements of these languages (s 1,1 , s 1,2 , ···), (s 2,1 , s 2,2 , ···), ··· can describe a set of tuples (sequences) of conjunctions of propositional atoms that can appear as positive (e.g., EgoInZoneY) or negative (e.g.,

Number

[0113] The interpretation mapping I 2 in L for S 2 can be given by the following formula:

Number

[0114] In this case, the subscript k is the position of s in the tuple i,k .

[0115] The interpretation mapping I of S in L 3 is given by the following formula: 3 [Mathematics] [Mathematics] and can be applied the same substitution as the case of S for the propositional atom s i,k . Intuitively, I 2 can mean that any s 2 in the specified order must become true at some point. In contrast, in the case of I i,k , it can be required that any s 3 must not hold until the next element s i,k+1 becomes true. That is, in particular, the point when s i,k is not satisfied cannot exist. This is quite possible in the case of I i,k . 2

[0116] For example, when the refinement R 2,3 and the abstraction A 3,2 are given by identity, [Mathematics] and [Mathematics] hold. Because [Mathematics] is. The refinement R 1,2 is s ∈ S 1It may be well defined by transforming it into disjunctive normal form. The set of tuples is obtained from disjunctions, and the tuples themselves are obtained from conjunctions. The reverse direction is abstraction A 2,1 results in this case. It should be noted that after PreadiziertEgoSubjektInZoneG2, all conjunctions in which PreadiziertEgoSubjektInZoneG1G2(k) is refined and ￢PreadiziertEgoSubjektInZoneG1G2(k) is deleted are refined. Because

Number

Number

Number

Number

Number

[0117] The first formal language S 1 Further exemplary specifications in are given as,

Number

Number

[0118] Additionally or alternatively, a computer-implemented method 200 for manufacturing a technical system according to a specification, in particular for manufacturing a vehicle or a part thereof that runs at least partially autonomously according to the specification, is further disclosed.

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

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

[0121] The method 200 may further include checking 240 how the first specification 10 and the second specification 20 behave relative to each other based on (based on the logic 50) logical implication

Number

Number

Number

[0122] Method 200 may be considered to be method 100 in all disclosed embodiments for this purpose, except that in method 200 the first specification is not necessarily converted from the time-dependent data 1. In other words, step 110 in method 100 may be considered unnecessary, and step 120 can be adjusted such that the first specification 10 in the first formal language 11 at the first level of abstraction is received.

[0123] A computer system is further disclosed that is configured to implement a computer-implemented method 100 for manufacturing a technical system according to a specification, in particular for manufacturing at least a partially autonomous vehicle or a part thereof according to the specification. The computer system may include a processor and / or a main memory.

[0124] A computer program is further disclosed that is configured to implement a computer-implemented method 100 for manufacturing a technical system according to a specification, in particular for manufacturing at least a partially autonomous vehicle or a part thereof according to the specification. The computer program may exist, for example, in an interpretable form or a compiled form. The computer program can be (partially) loaded into the RAM of a computer so as to be executed, for example, as a bit sequence or a byte sequence.

[0125] A computer-readable medium or signal storing and / or containing the computer program is further disclosed. The medium may include, for example, one of RAM, ROM, EPROM, HDD, SSD, etc., and the signal is stored on / in this medium.

Claims

1. A computer-implemented method (100) for manufacturing a technical system according to a specification, in particular for manufacturing a vehicle or a part thereof that drives at least partially autonomously according to a specification, comprising: The method (100) comprises: - receiving (110) time-dependent data (1) from at least one test of said technical system; - converting (120) the time-dependent data (1) into a first specification (10) in a first formal language (11) at a first abstraction level, the first formal language (11) having 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, said second formal language (21) having a second semantics defined by a second interpretation mapping (22) from said second formal language (21) to said logic (50); - checking (140) how the first specification (10) and the second specification (20) behave with respect to each other based on logical implications, in particular checking to what extent the first specification (10) covers the second specification (20) based on said logical implications (141) and / or to what extent the second specification (20) covers the first specification (10) (142); A method (100).

2. the first level of abstraction is the second level of abstraction; Optionally, the first formal language (11) is the second formal language (21).

2. The method of claim 1 (100).

3. said logic (50) being a temporal logic, in particular a linear temporal logic or a signal temporal logic, 3. The method (100) of claim 1 or 2.

4. Transforming (120) the time-dependent data (1) into the first specification (10) in the first formal language (11) at the first level of abstraction, comprising: - transforming (121) the time-dependent data (1) into a third specification (30) in a third formal language (31) at a third abstraction level, the third formal language (31) having a third semantics defined by a third interpretation mapping (32) from the third formal language (31) to the logic (50); - converting (122) said third specification (30) into said first specification (10); Including, The method (100) of any one of claims 1 to 3.

5. Transforming (122) the third specification (30) into the first specification (10) is an abstraction or elaboration.

5. The method (100) of claim 4.

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

7. Transforming (132) the fourth specification (40) into the second specification (20) is an abstraction or elaboration.

7. The method (100) of claim 6.

8. It is checked (141) whether the first specification (10) covers the second specification (20); The release of said technical system is subject to said first specification (10) covering said second specification (20), The method (100) of any one of claims 1 to 7.

9. It is checked (142) whether the second specification (20) covers the first specification (10); The release of the technical system is subject to the second specification (20) covering the first specification (10), The method (100) of any one of claims 1 to 8.

10. Based on the logical implication, it is checked (143) whether a first portion of the first specification (10) exceeds the second specification (20); Optionally, if such a first portion exists, extending said second specification (20) by a cut consisting of said first specification (10) and the negated second specification. The method (100) of any one of claims 1 to 9.

11. Based on the logical implication, it is checked (144) whether a second portion of the second specification (20) exceeds the first specification (10); Optionally, if such a second portion is present, generating at least one further test of said technical system based on a refinement of said second portion. The method (100) of any one of claims 1 to 10.

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

13. said technical system being a vehicle that drives at least partially autonomously, The logic (50) is a linear temporal logic, The linear temporal logic consists of the following proposition atoms: For each zone Z from the set of zones in which the vehicle can move, a UeberschneidungEgoZoneZ for the overlap of the vehicle with the zone Z; for each zone Z from the set of zones in which the further road user is movable, a UeberschneidungSubjektZoneZ for the overlap of said further road user with said zone Z; for each time step k from the set of time steps of the forecast horizon, a PraedizierteUeberschneidungEgoSubjekt_k for the predicted overlap of the vehicle with the further road user at said time step k of the forecast horizon; for each zone Z from the set of zones and for each time step k from the set of time steps of the forecast horizon, a PraedizierteUeberschneidungEgoZoneZ_k for the predicted overlap of the vehicle with the zone Z at the time step k of the forecast horizon; for each zone Z from the set of zones and for each time step k from the set of time steps of the forecast horizon, a PraedizierteUeberschneidungSubjektZoneZ_k for a predicted overlap of the further road user with the zone Z at the time step k of the forecast horizon; Including, The method (100) of any one of claims 1 to 12.

14. 14. A computer system configured to perform a computer-implemented method (100) according to any one of claims 1 to 13 for manufacturing a technical system according to a specification, in particular for manufacturing a vehicle or part thereof that drives at least partially autonomously according to a specification.

15. 14. A computer program for manufacturing a technical system according to a specification, in particular for manufacturing a vehicle or part thereof that drives at least partially autonomously according to a specification, the computer program being configured to perform a computer-implemented method (100) according to any one of claims 1 to 13.

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

Images