Structural Contracts – Motivating Contracts to Ensure Extra-Functional Semantics

. In our work we aim at a composable and consistent speciﬁ-cation and veriﬁcation of contracts for extra-functional properties, such as power consumption or temperature. To this end, a necessary precondition for the semantical correctness of such properties is to ensure the structurally correct modeling of their interdependences. While this can be solved by a tailoring of the Component Based Design (CmpBD) frameworks, the resulting design constraints are speciﬁc to tools and viewpoints, not being suﬃciently conﬁgurable for the designers. To solve this problem within the contract framework, Contract Based Design (CBD) with explicit port variables provides also no conﬁgurable but sound methodology for structurally relating the properties between diﬀerent components and views . For that, we propose the idea of Structural Contracts . Using implicit structural ports , structural guarantees can be given according to the Component Based Design structure. Expressing structural design constraints by the means of structural assumptions , the CmpBD constraints can become part of the Contract Based Design framework and, thus, can be checked for compatibility and reﬁnement. As a result, structural contracts enable the contract based speciﬁcation and veriﬁcation of structural rules for the correct modeling of functional and extra-functional interdependences. Providing both, property spec-iﬁcations and Component Based Design constraints by contracts, the approach is ﬂexible and sound.


Introduction
Following the increasing opportunities to integrate more functionality and improved performance in today's integrated microelectronic systems has lead to continuously growing design complexity and an increasing number and heterogeneity of design requirements. As a result, the specification, modeling and verification of such heterogeneous systems became a challenging task, requiring a reliable collaboration of specialists from different design and verification domains.
Following the paradigms of encapsulation, divide and conquer and separation of concerns the concepts of components and viewpoints have been introduced to master design complexity by Component Based Design (CmpBD) [9]. Commonly a component is considered to be a design element, which internally encapsulates its behavior, solely restricting its interaction with the environment to its welldefined port interface. Hence, a main precondition of Component Based Design is the components' behaviors to be compositional . That means, that for each point of time the interaction between connected components is clearly determined by solely one of the components, controlling the information exchange across this connection without being affected by undelayed influence from the environment.
Additionally, considering the further refinement and implementation of subcomponents to proceed independently, the compatibility of connected ports has to be ensured. To this end, type systems [6] are applied, to declare the type of the components' ports and to verify that connected ports have compatible types. Beyond the most common notion of untimed static types, such as boolean, integer etc., Contract Based Design (CBD) [3,11] enables a more dynamic notion of compatibility. By the means of the contracts' assumptions A all acceptable inputs of the components M are formally described by timed traces, declaring interconnections incompatible if the corresponding environment E is allowed to provide a timed sequence of outputs which violates the components' assumptions. Differently, when the assumptions are satisfied, the components provide outputs according to the guarantee G, which correspond to the satisfied assumption.
Nevertheless, static type and compatibility checking of contracts is not flexible enough to be applicable for the consistent specification and verification of the interactions between the properties from multiple extra-functional viewpoints, largely comprising physical properties w. r. t. power or temperature etc. Differently, a more flexible declaration of designer-defined types would be necessary, to allow for complex, derived and configurable types, which appropriately combine the value and time semantics of the ports with a viewpoint-specific physical interpretation, such as 'average power consumption per operation in µW '.
Considering viewpoint-specific models of a heterogeneous (multi-viewpoint) component to be viewpoint-specific components themselves, we assume that a sufficiently flexible but sound declaration and verification of designer-defined types can be achieved by extending the compatibility criteria of contracts to also structural properties, which constrain the basic design elements of the decomposition, such as the identifiers of components and ports. Since Contract Based Design allows contracts to constrain only the explicitly declared ports of components we propose a first concept of Structural Contracts. Based on an introspection of the component structure we implicitly instantiate a decomposition component plus structural ports and structural nets, to enable the contract based reflection of the component structure via these explicit ports. As a result, the usage of structural assumptions allows us to systematically constrain the instantiation and connection of subcomponents based on their component and port names.
To motivate our idea of structural contracts, Section 2 explains an artificial example, for which the extra-functional failure of the design becomes hidden -i. e. erroneously not visible -because of a semantically incorrect connection of extrafunctional ports. Next, in Section 3 we summarize the related work, before we introduce the formal basics of components and contracts in Section 4. In Section 5 we present our approach of structural contracts based on the introspection, component extension and contract based reflection of the component structure. Then, in Section 6 we outline a first proof of concept, using our initial example to successfully invalidate the previously hidden false negative verification using structural contracts. In Section 7 we conclude and give an outlook to future work.

Motivating Example
To motivate structural contracts we consider the simplified, artificial example of a composed component M given in Fig. 1, which is specified to hold an average power consumption of at maximum 20µW. The component has one functional input port x 0 , indicating two different operating modes, and one extra-functional output port y p , denoting the average power consumption per clock cycle.    Refining M by a composition of three different subcomponents, the subcomponents are M 0 , M 1 and M 2 , with all of them having one functional input x 0 and one functional output y 0 , decoding their operating mode in one bit. Moreover, for the purpose of calculating the power consumption, the subcomponents provide inputs x c and outputs y c , which describe the components' input or load capacitance C e sw , responsible for consuming a certain amount of power during the interaction of both components. Of course, in addition to that, each component consumes also an internal amount of power, based on the internally switched capacitance C i sw . For simplification, the example contains no further ports for the supply voltage V DD or clock frequency f clk , considering both of them to be constant at V DD = 1.0V and f clk = 2.0MHz for components M 1 and M 2 and M 0 .V DD = 1.0V and M 0 .f clk = 6.0MHz for component M 0 . Above that, following P = 1 2 V 2 DD f clk C sw the average power consumption y p = P depends on the average switched capacitance C sw = C i sw + C e sw , internally resp. externally switched according to the functional activity of the component. Appropriately to these specifications, Table 1 outlines the functional and extra-functional behavior of the components w. r. t. their input resp. output ports. For example, the switched capacitance of M 1 is 3pF for M.x 0 = 1. This is because of C Contrary to this, the same calculation of the power consumption asserts 'valid' when during refinement the following -semantically inconsistent -connection error occurs as given in Fig. 2. Refining M with n 6 and n 7 instead of n 1 and n 3 , the externally switched capacitances M 0 .y 0 and M 1 .y 0 are interchanged, leading to the erroneous power calculation M.y 0 = (x 0 ? 20 : 11) in Table 2.   Erroneously refining M with n 6 and n 7 instead of n 1 and n 3 , the semantical meaning of the capacitive loads, corresponding to the real worlds functional interconnections n 0 and n 2 gets violated. Without the possibility of strictly relating these ports by some concepts of derived complex types, such -and similar -semantic errors can easily remain unrevealed. As a solution to this, we propose structural contracts, to allow the designers to add composition constraints, and an introspection and reflection of the component structure, making the structural decomposition part of the contract-based specification and verification approach.

Related Work
Considering the related work -to the authors' best knowledge -no other work aims at ensuring the semantical consistency of different components and viewpoints -i. e. a verifiable but flexible type system with complex, designerdefined types -by a contract based formulation of constraints for the logical decomposition structure.
The probably most common approach to support semantical consistency and compatibility would be to provide only a limited set of fixed types of components and ports resp. design rules, which are defined and checked by the component based design framework. While this tailoring may support complex type systems, as e. g. the polymorphic and structured types [12] in Ptolemy II , it lacks flexibility w. r. t. defining viewpoint-specific compatibility and refinement rules, meaning constraints on how these types can bottom-up be constructed resp. top-down refined, checking value-, causality-and time-aware construction rules.
In interface theories [1,2] the distinction between bottom-up components for compositional abstraction on the one hand, and top-down interfaces for compositional design on the other hand have lead to the general concepts of compatibility and refinement checking for component specifications using assumptions and guarantees. Applying timed languages to describe assumptions and guarantees, the contracts allow to specify and to verify the compatibility of the components' interaction protocols according to value and time resp. causality criteria. Nevertheless -while building the general foundation for contracts based designwithout some introspection and reflection of the interface variables and their interconnection relations via additional ports, top-down constraints w. r. t. the logical decomposition structure are not possible that way.
Differently, to investigate and define behavioral types, in [4,5] the concepts of glue operators and glue constraints are defined for the BIP (behavior, interaction, priority) framework. Providing connectors with priorities and their own memoryless behavior the interaction between components connected by a connector can appropriately be synchronized w. r. t. to some timed or untimed causality relation. Hence, again compatibility is meant only in the sense of interaction protocols, not concerning extra-functional semantics of e. g. different viewpoints.

Formal Basics
As given in Fig. 1 Besides a function id(·) to resolve a port's name, the declaration of each port (·) defines also functions ν(·) to resolve its value domain -e. g. boolean or integer -and dir(·) ∈ {in, out} to resolve its direction as input resp. output.
Using an extended linear temporal logic, contracts C i := (A i , G i ) are used, to formally specify the assumptions A i of a component M w. r. t. to the timed behavior of its environment E, combined with its guarantees G i , provided for the case that the corresponding assumptions A i are satisfied. To this end, the assumptions describe expressions, which observe (read) only the input variables, while the guarantees are expressions, which control (write) only the output variables.  N) and ι ∈ N + 0 . Using the contracts' saturated interpretation (A i → G i ), with G i := (A i → G i ) and A i ⊆ A i , compositional assume/guarantee reasoning becomes possible to prove the compatibility and refinement within a component based decomposition.
Thus, we provide the component's contract based specification S M = i C i , which we onwards denote as behavioral specification. Accordingly, B M describes the corresponding behavioral implementation, e. g. given as an executable program, automata or formula. Furthermore, the tuple D M = (M * M , N M ) describes the component's structural decomposition, either for the purpose of a structural top-down refinement of the initial specification as well as for the structural bottom-up implementation by instantiation and integration of available components. Finally, the norm | · | shall for all sets denote their number of elements and, if necessary for unambiguousness, we prefix identifiers and symbols by component identifiers M or M i , using a dot as delimiter, as e. g. M 0 .C 0 , M 1 .C 0 , etc. For simplicity we identify components, contracts and ports by names equal to their symbols, so that id

Structural Contracts
In general, being based on interface theories, Contract Based Design is limited to such specifications S M , declaring only the externally observable 'behavioral properties' of the component -meaning 'behavioral' in that sense, that its properties refer only to the components' explicitly declared ports. Differently, the component's inherently contained 'structural properties' can neither be specified nor verified that way -meaning 'structural' not necessarily w. r. t. the physical but w. r. t. the logical structure, such as available ports, the instantiated subcomponents or the interconnection of a structural decomposition D M etc. As a solution, we suggest an introspection and reflection of these structural properties to introduce a structural point of view, enabling for structural contracts. According to the interface declaration (χ in M , χ out M ) and the formal decomposition D M we extract the available structural information and systematically add an implicit interface χ struc M of structural ports, which provide explicit access to the structural information. As a result, the component's decomposition structure becomes specifiable and verifiable via contract based constraints for its original interface declaration, structural decomposition resp. the instantiation and integration of the component within a hierarchical composition.
To explain our approach in detail, we follow its sequential steps according to: Based on these structural data types, we then introduce the structural introspection ports according to Fig. 3. That is, for each port p i ∈ χ Mi of each subcomponent M i ∈ M * M of the decomposition D M two additional input ports of type dt cId resp. dt pId are added. For each input port p i = x i ∈ χ in Mi the ports are named M i .id(x i ) cSrc and M i .id(x i ) pSrc resp. M i .id(y i ) cSnk and M i .id(y i ) pSnk for each output port p i = y i ∈ χ out Mi . Using these additional ports the components are enabled to receive information about the connections n i ∈ {N M , 'open'} between their original ports, meaning the identifiers of the 'source component' and 'source port' resp. the 'sink component' and 'sink port' connected via the net n i , resp. to receive 'open' if ports remained unconnected.
Finally, the introspection component M DM is annotated with structural guarantees C : ((A : true), (G : struc port = struc value )), reflecting the information of the original component's interconnections with struc value ∈ ν(struc port) and: struc port ∈

Proof of Concept
For a first proof of concept, we evaluated our approach of structural contracts for the motivating example, outlined in Sec. 2. To this end, we implemented the component interfaces of M and its subcomponents M 0 , M 1 and M 2 and provided them with contracts according to the functional and extra-functional properties given in Tab. 1. Based on this implementation we showed that structural contracts are able to reveal the false negative verification of the erroneous logical structure depicted in Fig. 2. Furthermore, we showed that for a correct structural decomposition our structural extension does not influence compatibility and refinement checking of the other functional and extra-functional properties. For the implementation and evaluation we used OTHELLO (Object Temporal with Hybrid Expressions Linear-Time LOgic) [8] for the specification of contracts and OCRA (OTHELLO Contracts Refinement Analysis) [7] to describe the components as OSS (OCRA System Specification) [7] and to check their compatibility and their refinement. To reproduce our study, our example is online available at [10].

Conclusion
Based on an artificial example we motivate the need for structural contracts and show how structural contracts increase the reliability of composed extra-functional multi-domain models. By the evaluation of the example we show that structural contracts can reveal failures in the logical composition structure, which otherwise remain hidden, enabling false negatives during extra-functional verification.
In the future work, we want to investigate the abstraction and refinement of our structural contracts and evaluate how structural contracts can be propagated throughout the design and abstraction hierarchies. Furthermore, we plan to examine if and which additional port annotations will become necessary enable this hierarchies and to allow for the seamless and composable integration of designer-defined extra-functional semantics based on structural contracts.