A Proposal for Verified Code Generation from Modelica

Transcription

1 A Proposal for Verified Code Generation from Modelica Bernhard Thiele PELAB Linköping University 04. February th MODPROD Workshop on Model-Based Product Development 1 / 22

2 Goals of this presentation Explain motivation for verified code generation. Introduce ACG-Modelica a proposal for a restricted Modelica subset for high-integrity code generation. Present a mapping of an ACG-Modelica subset to a synchronous data-flow kernel language for safety-related applications. 2 / 22

3 Safety-Related Model-Based Software Development Safety-related: Software failure may damage the environment, injure or kill people. = The risk stemming from such software needs to be reduced to a reasonable level. Consequences for development tools: Requirement to provide use-case dependent evidence for software tool suitability (Tool Qualification, see e.g., ISO 26262). = Particularly, validation of code generation from models. 3 / 22

4 Safety-Related Model-Based Software Development Safety-related: Software failure may damage the environment, injure or kill people. = The risk stemming from such software needs to be reduced to a reasonable level. Consequences for development tools: Requirement to provide use-case dependent evidence for software tool suitability (Tool Qualification, see e.g., ISO 26262). = Particularly, validation of code generation from models. 3 / 22

5 How to safeguard generated code? Two basic approaches: 1 Use generated code as if it was hand-generated: = Code is passed into the usual assurance process, i.e., code needs to be well-structured and obey reasonable guidelines for hand-generated code, code reviews on generated code. + No need for costly code generator qualification. Requires costly V&V efforts on generated code. 2 Use a certified/qualified code generator: = Need to provide evidence about tool suitability for the respective use-case. + Eliminates (some) V&V efforts on generated code, e.g., code reviews are done solely on model level rather than on embedded C source code level. Requires code generator qualification. 4 / 22

6 How to safeguard generated code? Two basic approaches: 1 Use generated code as if it was hand-generated: = Code is passed into the usual assurance process, i.e., code needs to be well-structured and obey reasonable guidelines for hand-generated code, code reviews on generated code. + No need for costly code generator qualification. Requires costly V&V efforts on generated code. 2 Use a certified/qualified code generator: = Need to provide evidence about tool suitability for the respective use-case. + Eliminates (some) V&V efforts on generated code, e.g., code reviews are done solely on model level rather than on embedded C source code level. Requires code generator qualification. 4 / 22

7 Consequences for Modelica Code Generation Generate readable code, particularly for support of 1 approach. Restrict language to ease qualification efforts, particularly for support of 2 approach. Bernhard Thiele, Stefan-Alexander Schneider, Pierre R. Mai. A Modelica Sub- and Superset for Safety-Relevant Control Applications. In 9 th Int. Modelica Conference, Munich, Germany, September Modelica Language High-Level Application Model Environment Model Specification Model sample(..) Plant Reference Qualifiable Modelica Subset Enrichment with implementation details hold(..) Code Generation Model Following presentation extends that previous work. 5 / 22

8 Consequences for Modelica Code Generation Generate readable code, particularly for support of 1 approach. Restrict language to ease qualification efforts, particularly for support of 2 approach. Bernhard Thiele, Stefan-Alexander Schneider, Pierre R. Mai. A Modelica Sub- and Superset for Safety-Relevant Control Applications. In 9 th Int. Modelica Conference, Munich, Germany, September Modelica Language High-Level Application Model Environment Model Specification Model sample(..) Plant Reference Qualifiable Modelica Subset Enrichment with implementation details hold(..) Code Generation Model Following presentation extends that previous work. 5 / 22

9 ACG-Modelica Proposal for a restricted language subset for high-integrity automatic code generation Restrict the valid language elements, e.g.: Clocked Variables Exclusivity: Only discrete-time clocked partitions as introduced in Modelica 3.3, Chapter Synchronous Language Elements are allowed. Restricted set of allowed keywords, operators and built-in functions (e.g., Only about 50% of the Modelica keywords are maintained). 6 / 22

10 ACG-Modelica Proposal for a restricted language subset for high-integrity automatic code generation Restrict the valid language elements, e.g.: Clocked Variables Exclusivity: Only discrete-time clocked partitions as introduced in Modelica 3.3, Chapter Synchronous Language Elements are allowed. Restricted set of allowed keywords, operators and built-in functions (e.g., Only about 50% of the Modelica keywords are maintained). 6 / 22

11 ACG-Modelica Proposal for a restricted language subset for high-integrity automatic code generation Simplified Modifications: Only one level of nesting supported (e.g., b(c=2) is OK, a(b(c=2)) is NOK). Causal data-flow semantics: Single variable (the unknown) is at the left-hand side and a flow expression is at the right-hand side (e.g., a = b c is valid while a + b = 0 or a 2 = b is invalid). Additional rules for the graphical representation to achieve semantical unambiguousness at the graphical layer. 7 / 22

12 ACG-Modelica Proposal for a restricted language subset for high-integrity automatic code generation Simplified Modifications: Only one level of nesting supported (e.g., b(c=2) is OK, a(b(c=2)) is NOK). Causal data-flow semantics: Single variable (the unknown) is at the left-hand side and a flow expression is at the right-hand side (e.g., a = b c is valid while a + b = 0 or a 2 = b is invalid). Additional rules for the graphical representation to achieve semantical unambiguousness at the graphical layer. 7 / 22

13 ACG-Modelica Proposal for a restricted language subset for high-integrity automatic code generation Simplified Modifications: Only one level of nesting supported (e.g., b(c=2) is OK, a(b(c=2)) is NOK). Causal data-flow semantics: Single variable (the unknown) is at the left-hand side and a flow expression is at the right-hand side (e.g., a = b c is valid while a + b = 0 or a 2 = b is invalid). Additional rules for the graphical representation to achieve semantical unambiguousness at the graphical layer. 7 / 22

14 Why Modular Code Generation Should be Supported Modular Code Generation: Preserve modularity of a block instance at source code level. Improves traceability between model and generated code. Facilitates to generate code that is is well-structured and obeys similar guidelines as hand-generated code. Allows straight forward separate compilation (advantage in respect to scalability and protection of intellectual property). Potentially decreased size of code footprint (block reusable function). 8 / 22

15 Why Modular Code Generation Should be Supported Modular Code Generation: Preserve modularity of a block instance at source code level. Improves traceability between model and generated code. Facilitates to generate code that is is well-structured and obeys similar guidelines as hand-generated code. Allows straight forward separate compilation (advantage in respect to scalability and protection of intellectual property). Potentially decreased size of code footprint (block reusable function). 8 / 22

16 Why Modular Code Generation Should be Supported Modular Code Generation: Preserve modularity of a block instance at source code level. Improves traceability between model and generated code. Facilitates to generate code that is is well-structured and obeys similar guidelines as hand-generated code. Allows straight forward separate compilation (advantage in respect to scalability and protection of intellectual property). Potentially decreased size of code footprint (block reusable function). 8 / 22

17 Why Modular Code Generation Should be Supported Modular Code Generation: Preserve modularity of a block instance at source code level. Improves traceability between model and generated code. Facilitates to generate code that is is well-structured and obeys similar guidelines as hand-generated code. Allows straight forward separate compilation (advantage in respect to scalability and protection of intellectual property). Potentially decreased size of code footprint (block reusable function). 8 / 22

18 Why Modular Code Generation Should be Supported Modular Code Generation: Preserve modularity of a block instance at source code level. Improves traceability between model and generated code. Facilitates to generate code that is is well-structured and obeys similar guidelines as hand-generated code. Allows straight forward separate compilation (advantage in respect to scalability and protection of intellectual property). Potentially decreased size of code footprint (block reusable function). 8 / 22

19 Translation to a Synchronous Data-Flow Kernel (SDFK) Goal Mapping of ACG-Modelica to a synchronous data-flow kernel language for which compilation techniques are known that are well-understood and accepted by certification authorities. Approach: 1 Define a representative language kernel for ACG-Modelica (further denoted as macg-modelica). 2 Define a set of formal translation equations from macg-modelica to SDFK. Argue that the semantics of macg-modelica are defined in terms of that translation (translational semantics). Reasoning If translation exists it opens up a path to a qualifiable compiler for ACG-Modelica. 9 / 22

20 Translation to a Synchronous Data-Flow Kernel (SDFK) Goal Mapping of ACG-Modelica to a synchronous data-flow kernel language for which compilation techniques are known that are well-understood and accepted by certification authorities. Approach: 1 Define a representative language kernel for ACG-Modelica (further denoted as macg-modelica). 2 Define a set of formal translation equations from macg-modelica to SDFK. Argue that the semantics of macg-modelica are defined in terms of that translation (translational semantics). Reasoning If translation exists it opens up a path to a qualifiable compiler for ACG-Modelica. 9 / 22

21 Translation to a Synchronous Data-Flow Kernel (SDFK) Goal Mapping of ACG-Modelica to a synchronous data-flow kernel language for which compilation techniques are known that are well-understood and accepted by certification authorities. Approach: 1 Define a representative language kernel for ACG-Modelica (further denoted as macg-modelica). 2 Define a set of formal translation equations from macg-modelica to SDFK. Argue that the semantics of macg-modelica are defined in terms of that translation (translational semantics). Reasoning If translation exists it opens up a path to a qualifiable compiler for ACG-Modelica. 9 / 22

22 Translation to a Synchronous Data-Flow Kernel (SDFK) Goal Mapping of ACG-Modelica to a synchronous data-flow kernel language for which compilation techniques are known that are well-understood and accepted by certification authorities. Approach: 1 Define a representative language kernel for ACG-Modelica (further denoted as macg-modelica). 2 Define a set of formal translation equations from macg-modelica to SDFK. Argue that the semantics of macg-modelica are defined in terms of that translation (translational semantics). Reasoning If translation exists it opens up a path to a qualifiable compiler for ACG-Modelica. 9 / 22

23 The SDFK target language The synchronous data-flow kernel is presented in: D. Biernacki, J.-L. Colaço, G. Hamon, and M. Pouzet. Clock-directed modular code generation for synchronous data-flow languages. SIGPLAN Not., 43(7): , June That article: Describes modular code generation from that kernel into imperative code. basic calculus that is powerful enough to express any Lustre program. The principles presented in this article are implemented in the RELUC compiler of SCADE/LUSTRE and experimented on industrial real-size examples. The commercial Lustre-based Scade tool provides a code generator, KCG, that already has been successfully qualified for safety-critical applications. 10 / 22

24 The SDFK target language The synchronous data-flow kernel is presented in: D. Biernacki, J.-L. Colaço, G. Hamon, and M. Pouzet. Clock-directed modular code generation for synchronous data-flow languages. SIGPLAN Not., 43(7): , June That article: Describes modular code generation from that kernel into imperative code. basic calculus that is powerful enough to express any Lustre program. The principles presented in this article are implemented in the RELUC compiler of SCADE/LUSTRE and experimented on industrial real-size examples. The commercial Lustre-based Scade tool provides a code generator, KCG, that already has been successfully qualified for safety-critical applications. 10 / 22

25 The SDFK target language The synchronous data-flow kernel is presented in: D. Biernacki, J.-L. Colaço, G. Hamon, and M. Pouzet. Clock-directed modular code generation for synchronous data-flow languages. SIGPLAN Not., 43(7): , June That article: Describes modular code generation from that kernel into imperative code. basic calculus that is powerful enough to express any Lustre program. The principles presented in this article are implemented in the RELUC compiler of SCADE/LUSTRE and experimented on industrial real-size examples. The commercial Lustre-based Scade tool provides a code generator, KCG, that already has been successfully qualified for safety-critical applications. 10 / 22

26 The SDFK target language The synchronous data-flow kernel is presented in: D. Biernacki, J.-L. Colaço, G. Hamon, and M. Pouzet. Clock-directed modular code generation for synchronous data-flow languages. SIGPLAN Not., 43(7): , June That article: Describes modular code generation from that kernel into imperative code. basic calculus that is powerful enough to express any Lustre program. The principles presented in this article are implemented in the RELUC compiler of SCADE/LUSTRE and experimented on industrial real-size examples. The commercial Lustre-based Scade tool provides a code generator, KCG, that already has been successfully qualified for safety-critical applications. 10 / 22

27 The SDFK target language The synchronous data-flow kernel is presented in: D. Biernacki, J.-L. Colaço, G. Hamon, and M. Pouzet. Clock-directed modular code generation for synchronous data-flow languages. SIGPLAN Not., 43(7): , June That article: Describes modular code generation from that kernel into imperative code. basic calculus that is powerful enough to express any Lustre program. The principles presented in this article are implemented in the RELUC compiler of SCADE/LUSTRE and experimented on industrial real-size examples. The commercial Lustre-based Scade tool provides a code generator, KCG, that already has been successfully qualified for safety-critical applications. 10 / 22

28 Multi-Level Translation Approach Translation to SDFK is achieved in two steps: 1 Normalization of macg-modelica (source-to-source transformation) 1 Generation of connection equations. (will omit that) 2 Strip parameter modifications, normalize component modifications and extract component dot accesses appearing in expressions. 3 Create a fresh block that instantiates the top-level block as a component with normalized component modifications. (will omit that) 2 Translation to SDFK Normalization and translation are defined as a set of mutually recursive functions. This talk: No formal equations, just the basic ideas. 11 / 22

29 Multi-Level Translation Approach Translation to SDFK is achieved in two steps: 1 Normalization of macg-modelica (source-to-source transformation) 1 Generation of connection equations. (will omit that) 2 Strip parameter modifications, normalize component modifications and extract component dot accesses appearing in expressions. 3 Create a fresh block that instantiates the top-level block as a component with normalized component modifications. (will omit that) 2 Translation to SDFK Normalization and translation are defined as a set of mutually recursive functions. This talk: No formal equations, just the basic ideas. 11 / 22

30 Multi-Level Translation Approach Translation to SDFK is achieved in two steps: 1 Normalization of macg-modelica (source-to-source transformation) 1 Generation of connection equations. (will omit that) 2 Strip parameter modifications, normalize component modifications and extract component dot accesses appearing in expressions. 3 Create a fresh block that instantiates the top-level block as a component with normalized component modifications. (will omit that) 2 Translation to SDFK Normalization and translation are defined as a set of mutually recursive functions. This talk: No formal equations, just the basic ideas. 11 / 22

31 Multi-Level Translation Approach Translation to SDFK is achieved in two steps: 1 Normalization of macg-modelica (source-to-source transformation) 1 Generation of connection equations. (will omit that) 2 Strip parameter modifications, normalize component modifications and extract component dot accesses appearing in expressions. 3 Create a fresh block that instantiates the top-level block as a component with normalized component modifications. (will omit that) 2 Translation to SDFK Normalization and translation are defined as a set of mutually recursive functions. This talk: No formal equations, just the basic ideas. 11 / 22

32 Multi-Level Translation Approach Translation to SDFK is achieved in two steps: 1 Normalization of macg-modelica (source-to-source transformation) 1 Generation of connection equations. (will omit that) 2 Strip parameter modifications, normalize component modifications and extract component dot accesses appearing in expressions. 3 Create a fresh block that instantiates the top-level block as a component with normalized component modifications. (will omit that) 2 Translation to SDFK Normalization and translation are defined as a set of mutually recursive functions. This talk: No formal equations, just the basic ideas. 11 / 22

33 Normalization Parameter and Component Modifications Parameter modifications in a class are stripped away: block PI parameter Real kd = Td * 2 ; parameter Real Td = 0. 1 ; end PI ; block PI parameter Real kd ; parameter Real Td ; end PI ; All parameters of an instantiated class are extracted, merged with applicable instance modifications and introduced as new parameters with a modification expression: block A parameter Real k ; parameter Real Td=0. 2 ; PI p i ( Td=Td ) ; end A ; block A parameter Real k ; parameter Real Td ; parameter Real _pi_kd=_pi_td * 2 ; parameter Real _pi_td=td ; PI p i ( kd=_pi_kd, Td=_pi_Td ) ; end A ; 12 / 22

34 Normalization Parameter and Component Modifications Parameter modifications in a class are stripped away: block PI parameter Real kd = Td * 2 ; parameter Real Td = 0. 1 ; end PI ; block PI parameter Real kd ; parameter Real Td ; end PI ; All parameters of an instantiated class are extracted, merged with applicable instance modifications and introduced as new parameters with a modification expression: block A parameter Real k ; parameter Real Td=0. 2 ; PI p i ( Td=Td ) ; end A ; block A parameter Real k ; parameter Real Td ; parameter Real _pi_kd=_pi_td * 2 ; parameter Real _pi_td=td ; PI p i ( kd=_pi_kd, Td=_pi_Td ) ; end A ; 12 / 22

35 Normalization Extract Component Dot Accesses Component dot accesses in RHS equations are extracted: block PI input Real u ; output Real y ; equation y = u ; end PI ; block A output Real y ; PI p i ; equation p i. u = 3; y = pi.y + 2; end A ; block PI input Real u ; output Real y ; equation y = u ; end PI ; block A output Real y ; PI p i ; Real _t1; equation p i. u = 3; _t1 = pi.y; y = _t1 + 2; end A ; 13 / 22

36 Translation of Normalized PI to SDFK Inputs + Parameters without mod. node input arguments Outputs node return values Delays + start values initialized delay (0 fby x) block PI input Real u ; output Real y ; parameter Real kd ; parameter Real Td ; Real x ( s t a r t = 0 ) ; equation x = previous ( x ) + u / Td ; y = kd * ( x + u ) ; end PI ; node PI ( Td : real, kd : real, u : r e a l ) = y : r e a l with var x : r e a l in x = 0 fby x + u / Td and y = kd * ( x + u ) 14 / 22

37 Translation of Normalized A to SDFK Parameters with mod. Local var + equation Instance mod. + dot-access Function like node instance call block A input Real ua ; output Real ya ; parameter Real k ; parameter Real Td ; parameter Real _pi_kd=_pi_td*2; parameter Real _pi_td=td; PI pi(kd=_pi_kd, Td=_pi_Td); Real _t1 ; equation pi.u = ua * k ; _t1 = pi.y ; ya = _t1 ; end A ; node A ( Td : real, k : real, ua : r e a l ) = ( ya : r e a l ) with var _pi_kd:real, _pi_td:real, _t1 : r e a l in _pi_kd = _pi_td*2 and _pi_td = Td and ya = _t1 and _t1 = PI(_pi_Td, _pi_kd, ua*k) 15 / 22

38 Implementation Formal translation equations have been implemented in a proof-of-concept translator using the Scala language. Implementation includes an emitter from SDFK to Lustre. The freely available academic LUSTRE V4 TOOLBOX 1 can be used to generate C-code from Lustre. The C-code can be interfaced back to Modelica for convenient back-to-back testing / 22

39 Implementation Formal translation equations have been implemented in a proof-of-concept translator using the Scala language. Implementation includes an emitter from SDFK to Lustre. The freely available academic LUSTRE V4 TOOLBOX 1 can be used to generate C-code from Lustre. The C-code can be interfaced back to Modelica for convenient back-to-back testing. Back-to-back testing of Block A parameter k = 1.0 parameter T_d = 0.2 input ua = unit step at tick / 22

40 Questions? 17 / 22

41 Other PI Example SDFK Grammar td ::= type bt type bt = C C d ::= node f(p) = p with var p in D p ::= x : bt;...;x : bt D ::= pat = a D and D pat ::= x (pat,...,pat) a ::= e ck e ::= v x (a,...,a) v fby a op(a,...,a) f(a,...,a) every a a when C(x) merge x (C a)...(c a) if x then a else a v ::= C i ct ::= ck ct... ct ck ::= base ck on C(x) if x then e 2 else e 3 = merge x (True e 2 when True(x)) (False e 3 when False(x)) 18 / 22

42 Other PI Example macg-modelica Grammar td ::= Boolean Integer Real d ::= block id p equation D end; tm ::= input parameter output p ::= p p t x; t x mo; tm t x; tm t x mo; mo ::= (ar,..., ar) = e ar ::= id = v D ::= D D eq; e ::= x op(e,...,e) previous(x) if e then e else e eq ::= x = e connect(x,x) x ::= c id id denotes a variable c ::= id. No deep nesting allowed! v = value id = identifier Only one level of modification nesting supported. (No elseif) 19 / 22

43 Other PI Example PI Controller Example Connector declarations: connector In = input Real ; connector Out = output Real ; PI-block: block PI In u ; Out y ; parameter Real kd = Td * 2 ; parameter Real Td = 0. 1 ; Real x ( s t a r t = 0 ) ; equation x = previous ( x ) + u / Td ; y = kd * ( x + u ) ; end PI ; Block A instantiating PI: block A In ua ; Out ya ; parameter Real k ; parameter Real Td=0. 2 ; PI p i ( Td=Td ) ; equation p i. u = ua * k ; connect ( ya, p i. y ) ; end A ; 20 / 22

44 Other PI Example Instantiation of Block A Block A: block A In ua ; Out ya ; parameter Real k ; parameter Real Td=0. 2 ; PI p i ( Td=Td ) ; equation p i. u = ua * k ; connect ( ya, p i. y ) ; end A ; Normalized instance block of A: block _Inst_A input Real ua ; output Real ya ; parameter Real _a_k ; parameter Real _a_td=0. 2 ; A a ( k=_a_k, Td=_a_Td ) ; equation a.ua = ua ; ya = a.ya ; end _Inst_A ; 21 / 22

45 Other PI Example Translation of Instantiated Block A to SDFK Remember Normalization Step 3: Create a fresh block that instantiates the top-level block as a component with normalized component modifications. Instantiate block A: block _Inst_A input Real ua ; output Real ya ; parameter Real _a_k ; parameter Real _a_td=0. 2 ; A a(k=_a_k, Td=_a_Td) ; equation a.ua = ua ; ya = a.ya ; end _Inst_A ; SDFK node of _Inst_A: node _Inst_A ( _a_k : f l o a t, ua : f l o a t ) = ya : f l o a t with var _a_td : f l o a t in ya = A( _a_k, _a_td, ua ) and _a_td = / 22