Applied veRification for Continuous and Hybrid Systems Industrial Examples of Formal Specifications for Test Case Generation

While requirements engineering has received considerable attention in academia over the past years, formalization of requirements for physically influenced systems is still a difficult task in practice. In this paper, we give formal representations of some typical requirement classes arising in the automotive industry. We divide these patterns into three main classes: those mostly referring to properties of continuous signals, those mostly referring to discrete events and those referring to similarity to a reference signal. We discuss these patterns on concrete examples from automotive embedded systems, where specifications are used for test case generation. Category: industrial Difficulty: medium 1 Context and Origins Deriving formal specifications for industrial embedded systems is a challenging task. In this paper, we discuss some typical patterns of such specifications as well as challenges when trying to represent the requirements in existing formalisms. One major use case for the derived formal specification is test case generation, i. e., systematically deriving test cases from specifications. In this paper we discuss typical specification patterns occuring in the automotive domain, for test case generation approaches see [3] and [6], for instance. From an industry perspective, it is important to note that formalized specifications for physically-driven systems will usually form an incomplete picture, as there are requirements which are simply not amenable to suitable formalization at this point. This includes requirements on how driving is supposed to “feel” for the customer. Also, some requirements (like noise levels or vibrations inside the car) may be formalizable, but since there are usually no useful physical models for these effects, the specification cannot be leveraged. However, we believe that formal specifications even of subsets of requirements, together with adequate physical models are still very useful, since the development process can be accelerated with help of formal methods. For the specifications given in this paper, we generally use preand postconditions. Here, a precondition A describes the assumptions made on the environment under which the required behavior, a postcondition B, is supposed to hold. The examples raise the question what are suitable formalisms for A and B to cover a large class of requirements. Usually, A will be tightened for testing purposes. While a specification might require B to hold under a large 80 G.Frehse and M.Althoff (eds.), ARCH15 (EPiC Series in Computer Science, vol. 34), pp. 80–88 Industrial Examples of Formal Specifications Roehm, Gmehlich, Heinz, Oehlerking, and Woehrle Controller Plant Demanded position (dp) Torque limit (tl) Current position (cp)

[1]  Mirko Conrad,et al.  Automatic Evaluation of ECU Software Tests , 2005 .

[2]  Benjamin Wilmes,et al.  Considering Signal Constraints in Search-Based Testing of Continuous Systems , 2010, 2010 Third International Conference on Software Testing, Verification, and Validation Workshops.

[3]  Sriram Sankaranarayanan,et al.  Verification of automotive control applications using S-TaLiRo , 2012, 2012 American Control Conference (ACC).

[4]  Lionel C. Briand,et al.  Automated Model-in-the-Loop Testing of Continuous Controllers Using Search , 2013, SSBSE.

[5]  Jyotirmoy V. Deshmukh,et al.  Benchmarks for Model Transformations and Conformance Checking , 2014 .

[6]  Kenneth R. Butts,et al.  Powertrain control verification benchmark , 2014, HSCC.

[7]  Houssam Abbas,et al.  Formal property verification in a conformance testing framework , 2014, 2014 Twelfth ACM/IEEE Conference on Formal Methods and Models for Codesign (MEMOCODE).

[8]  Sanjit A. Seshia,et al.  Mining Requirements From Closed-Loop Control Models , 2015, IEEE Trans. Comput. Aided Des. Integr. Circuits Syst..