Contract Replaceability for Ensuring Independent Design using Assume-Guarantee Contracts

Complexity and heterogeneity are fundamental challenges for system design, as they prolong the design process and increase its cost. Independent design is a promising design flow to address these challenges whereby a supplier can develop its component without exchanging system-level information with other suppliers. Recent research on assume-guarantee contracts and contract-based design has focused on algebraic concepts, such as refinement and composition, to achieve independent design. However, the conventional definition of assume-guarantee contracts may result in implementations that may not operate correctly in the targeted environment of the system, thus hindering independent design. In this paper, we introduce the concept of contract replaceability, a binary relation on contracts that prevents this problem. We then extend the requirements to include receptiveness as a constraint on assume-guarantee contracts to ensure strong replaceability. The properties derived from the constraints ensure that strong replaceability is satisfied under contract refinement and cascade composition. Thus any assume-guarantee contract that satisfies this constraint permits independent design

that utilizes contracts in platform-based design.It applies refinement and abstraction to reduce complexity and separates orthogonal viewpoints, or aspects, of a design to handle the heterogeneity of the design [3].Among many formalisms, assume-guarantee contracts, consisting of an assumption set and a guarantee set, are attractive in research because of their ease of use.The close-formed formulas of the assumeguarantee contract operations, such as composition and quotient [14], [23], have been derived to facilitate contract-based design.
Independent design [4] is a benefit brought by contractbased design.It allows earlier verification of the system and protects the trade secrets between designers and suppliers.In the independent design paradigm, system-level specifications are refined with more detailed information and decomposed into multiple parts where the composition of these parts satisfies the system-level specifications.The refinement and decomposition ensure that the system meets the top-level requirement once each part follows its local specification.Every supplier thus can independently develop the part under its specification without the system-level specifications or coordination between the suppliers.As a result, the paradigm captures design faults at the specification stage to avoid costly and time-consuming redesign processes and protects the highlevel design ideas from leaking to the suppliers, which might be different companies.
Fig. 1 shows the ideal flow of independent design.First, the top-level specification for the product is decomposed into the specifications of multiple subsystems or parts.These specifi-Abstract-Complexity and heterogeneity are fundamental challenges for system design, as they prolong the design process and increase its cost.Independent design is a promising design flow to address these challenges whereby a supplier can develop its component without exchanging system-level information with other suppliers.Recent research on assume-guarantee contracts and contract-based design has focused on algebraic concepts, such as refinement and composition, to achieve independent design.However, the conventional definition of assume-guarantee contracts may result in implementations that may not operate correctly in the targeted environment of the system, thus hindering independent design.In this paper, we introduce the concept of contract replaceability, a binary relation on contracts that prevents this problem.We then extend the requirements to include receptiveness as a constraint on assume-guarantee contracts to ensure strong replaceability.The properties derived from the constraints ensure that strong replaceability is satisfied under contract refinement and cascade composition.Thus any assume-guarantee contract that satisfies this constraint permits independent design.

I. INTRODUCTION
As the needs for large-scale systems, such as autonomous driving, industry 4.0, and artificial intelligence-based applications, increased over the last decades, complexity and heterogeneity have become the main challenges that prolong the design process and increase its cost [24], [25].Several methodologies and algorithms have been proposed to cope with design complexity and heterogeneity in all design aspects including specification, verification, and synthesis [7], [20], [21], [25].Among them, design specification is crucial, as it is the first stage in a rigorous design flow.Methodologies for design specification affect efficiency in verification and synthesis, the subsequent stages of a design flow.
Contract-based design [19], [25] tackles complexity and heterogeneity coupled with platform-based design and formal specifications and thus has become a promising candidate for facilitating complex and heterogeneous design.Contracts are formal specifications [4] for the design environment and its implementation.Contract-based design is a methodology cations of the parts are sent to different suppliers proficient in the domain knowledge to design and provide implementations for the parts.These suppliers can refine their specifications, add more detailed information to the specification, or further decompose the part specification into more part specifications and then delegate them to subsequent suppliers for implementation.After a provider completes an implementation, the implementation is sent back to the system integrator and composed into the target system.
However, the machinery of assume-guarantee contracts does not rule out that the implementations generated for systems or components may not operate correctly in their targeted environments.These implementations, which we call vacuous implementations, have empty sets of behaviors in the targeted environment (i.e., not compatible with the environment).Therefore, vacuous implementations should be avoided in the independent design flow.As these vacuous implementations are not excluded from the standard contract framework, additional requirements and constraints enforced on contracts are required to support independent design using assumeguarantee contracts.
In this work, we investigate the requirements and additional constraints on assume-guarantee contracts to provably avoid vacuous implementations.Our contributions are the following: • We identify the vacuous implementation problem as an obstacle to the independent design paradigm.To the best of our knowledge, this is the first work that discovers and addresses this problem of the application of the contractbased design methodology to independent design.• We introduce replaceability, a binary relation, as a sufficient condition to prevent the vacuous implementation problem.A refinement of a contract that follows replaceability is guaranteed to contain implementations compatible with the contract.• We then introduce strong replaceability, a transitive binary relation, as a restriction on refinement to prevent the vacuous implementation problem in successive refinement steps and enable the independent design.Strong replaceability relieves the need for system contracts to enforce the requirement of replaceability.Once each refinement step follows strong replaceability, the resulting contract must follow replaceability with the system contract.• We introduce the concept of receptiveness as a property of assume-guarantee contracts.We show that receptiveness is sufficient to ensure strong replaceability, and the independent design paradigm is permitted on receptive contracts for refinement and cascade composition.
The remainder of the paper is organized as follows: Section II introduces assume-guarantee contracts.Section III describes the vacuous implementation problem and formulates the contract replaceability requirement.Section IV proposes the notion of contract receptiveness.Section V and Section VI show that contract receptiveness ensures strong replaceability in refinement and cascade composition, respectively.Finally, Section VIII concludes the paper.

II. PRELIMINARIES
This section introduces the elements in assume-guarantee contracts, the contract-based design methodology, and their background.

A. Variables, Behaviors, and Projections
A system specification defines its interaction with the external environment.The interaction is represented by the behaviors over the variables of the system.a) Variables: For our purposes, the variable is the port of the system that interacts with the external environment.Each variable is associated with a variable type, the set of values the variable can take.The collection of all variables in the system is the variable set of the system, denoted by V .For example, a logical AND gate with input ports a and b, and output port c has the variable set V = {a, b, c}, and the variable types for a, b, and c are the Boolean domains B.
b) Behaviors and Components: A behavior is a successive assignment of values to the variables in the system.Take the logical AND gate for example, (a, b, c) = (T, T, T ), (T, F, F ), (F, F, F ) . . . is one behavior.To simplify notation, in our examples, we will denote behaviors statically, i.e., taking constant values for all time steps.However, all of the definitions and properties used throughout the paper can be applied to arbitrary behaviors.
For a variable v ∈ V , we denote the universe of the behaviors over the variable v by B v .The universe of system behaviors over the variable set V , represented as B V , is defined by the direct product of the universe of behaviors for all system variables, i.e., v∈V B v .For example, the universe of the behaviors over the variable set of the logical AND gate is A component M ⊆ B V is a set of behaviors.We understand the component as containing the behaviors that one can observe from it.The behavior set can be expressed as a predicate over the variables.All behaviors leading to the truth value of the predicate belong to the behavior set.In the logical AND gate example, the behavior set is If the variable set is well-known in the context, we can express the behavior set using only the predicate: a∧b = c.Elaboration on these syntactic issues can be found in Chapter 7 of [12].
The composition of two components M 1 and M 2 is the intersection of both behavior sets M 1 ∩M 2 .We understand this intersection as the simultaneous enforcement of the constraints imposed by M 1 and M 2 on the system's behaviors.In other words, the composition of two components can be represented as the conjunction of their predicates (i.e., constraints).c) Projections of Behaviors: We will often need to map behaviors to behaviors defined over a different set of variables.To define this map, we first define the behaviors restricted to a single variable v ∈ V .
Let e ∈ B V be a behavior and v ∈ V , we denote e v as the behavior restricted to the variable v.
Here we define the projection of behaviors.Let V and V be two variable sets and B V ⊆ B V be a set of behaviors defined in V , the projection of behaviors B V to variables V is as follows: Each behavior e after the projection corresponds to some behavior e ∈ B V , sharing the same assignments for the common variables and having arbitrary assignments for the variables not in V .Take the logical AND gate as an example again, the projection of its behavior to variables {b, c} is (b, c) ∈ B 2 ¬c ∨ b .Consider another example of the removal of a variable and the inclusion of an additional variable at the same time.If we are considering the system which contains an additional input d that is unrelated to this logical AND gate, the projection to variables {b, c, d} is Regarding notation, if e is a behavior, we will sometimes write Π V (e) to mean Π V ({e}).Similarly, when Π V (e) is a singleton, we will sometimes use Π V (e) to denote the element it contains.In those cases, we may see statements such as

B. Assume-Guarantee Contracts and Contract-Based Design
An assume-guarantee contract C, as a formal specification for a system, is a pair of behavior sets (A, G), where A is the assumption set, and G is the guarantee set.Both behavior sets share the same contract variable set V C , the collection of all ports in the system.The assumption set specifies the targeted environments where the system is expected to operate.The guarantee set describes the acceptable behaviors when the system operates under the targeted environment.When the system operates in an environment not specified by the assumption set, all behaviors are acceptable.As a result, the acceptable behavior set of a contract C = (A, G) is G ∪ A. An implementation of the contract is a component M C which meets the contract.Therefore, the behavior set of an implementation must satisfy M C ∩ A ⊆ G, and it is thus any subset of the acceptable behavior set: A contract is a saturated contract if it satisfies G ∪ A = G, meaning that the guarantee set includes all the acceptable behaviors.Any contract can be saturated by replacing C = (A, G) with (A, G ∪ A).The semantics of the specification remains unchanged, as saturation does not change the acceptable behaviors.
Contract-based design is a design methodology that specifies a system using contracts and exploits the theory of contracts to operate on the contracts during the design process.The refinement and the composition are the main operations in contract-based design.The refinement increases the details of the specifications, and composition integrates multiple subsystem contracts into a contract for the entire system.The contract-based design process is as follows: First, the designers specify a system-level contract to reflect the goal of the design.The contract is then refined and decomposed into multiple subsystem contracts whose composition refines the original contracts.The process continues until the detail of the contract for each subsystem is sufficient for actual implementation, such as a circuit layout, a CAD model for a mechanical part, and the control parameters for a controller design.The contract-based design leverages this hierarchical flow and abstraction of the system to tackle design complexity and capture design faults earlier to avoid long design cycles.
The assume-guarantee contracts support the composition and the refinement for contract-based design using the set operations [25].
For a given contract C = (A, G) we define the nonassumption variables V G and the assumption variable set V A .The non-assumption variable set is a subset of V C that is insensitive to the assumption set, defined formally as follows: The intuition of the definition is that the value of the nonassumption variable does not affect the satisfaction of the assumption for all behaviors.The set ) contains all behaviors that have the same value as e for all variables except for v.
The assumption variable set V A is defined as For example, considering the contract

C. Related Work
The notion of contracts derives from a software engineering technique using preconditions and postconditions to specify and verify a program method.Once the preconditions, the responsibilities of the caller, are satisfied, the method ensures the postconditions.Variants of these specifications are also proposed to reason different systems.For example, Jones [15] proposes rely-guarantee reasoning for concurrent programming, adding rely-conditions, the assumptions on the changes of global states made by other processes, and guarantee conditions, the changes of global states that can be made by the programs itself.Meyer [17] was the first to use the term "contract" in its proposed design methodology, as an analogy to business contracts between the caller of function and the function itself.
The contracts are later adopted in the (cyber-physical) system design domain for formal verification and specifications of components operating in parallel.Abadi et al. [1], [2] was the first to represent specifications as assumptions and guarantees for Transition Systems and their composition.Sangiovanni-Vincentelli et al. [25] then developed the contract-based design methodology, which utilizes contracts in the platform-based design for cyber-physical system designs.The contracts in the methodology include horizontal contracts and vertical contracts.The horizontal contracts describe the interactions of the components in the same level of abstraction, and the vertical contracts capture additional assumptions between different levels of abstraction.Applications of the contractbased design methodology to build a systematic design flow, such as aircraft Electricity Power System [21] and analog system interface design [20], have demonstrated its potentials in handling complex design problems.Extensions of contracts formalism are also proposed in different applications, such as optimization of controller designs [22], stochastic systems [19], and hyperproperties [13] We refer interested readers to Chapter 3 of the monograph by Benveniste et al. [4], which provides a comprehensive background of contracts in software engineering and their adoption by the cyber-physical domain in formal verification and specification.
This paper focuses on the problem in the application of refinement in contract-based design.Many works have proposed algorithms for verifying and generating refinement of contracts.Cimatti et al. [5], [6] proposed the property-based proof systems to check whether a system is refined by the submodule contracts.The algorithm tests whether the guarantees generated by all submodules satisfy the top-level guarantees, and any top-level environments operating with all submodules create an environment for each submodule.Le et al. [16] proposed a similar paradigm more generically by defining a set of metatheoretical operators which allows the proof strategy to apply in different contract frameworks.Iannopollo et al. [9] adopted a hierarchical verification strategy and proposed a library-based contract refinement checking algorithm.The algorithm utilizes pre-checked refinement relations in the library to accelerate the verification.Iannopollo et al. [8], [10] also proposed a counter-example guided inductive synthesisbased constrained synthesis flow to synthesize contracts from a library of components or contracts specified using linear temporal logic.Their subsequent work [11] improves the synthesis efficiency by hierarchically decomposing the contracts into smaller contracts.These works are not aware of the potential vacuous implementation problem in the refinement process, the key enabler of the independent design paradigm.To the best of our knowledge, this is the first work that formally defines the requirement for independent design using contracts and introduces constraints to address the problem.As a result, this work complements the algorithms and tools by identifying the requirements for ensuring independent design.By enforcing the requirements, independent design can be ensured using the contract-based design without worrying about the vacuous implementation problem.
Receptiveness is the foundation for our proposed receptive contracts.The concept of receptiveness, which originates from the implementation point of view, was first proposed in [3], where receptiveness is defined over behaviors as any values Fig. 2: A scenario that all implementations in the refined contract are vacuous implementations since they form an empty set when intersecting with the original contract assumption.
for the specified variables corresponding to some behaviors restricted by an assertion.Then the consistency of a contract is defined as the guarantee being u-receptive, where u stands for the uncontrolled variables in the variable set.The same notion for receptiveness was also mentioned in the later works [4], [5], [7], [25], while the contract consistency was defined differently in [4], [14] as contracts containing nonempty implementations set.
However, these works do not show the relation of receptiveness to the ability of independent design, as they intend to ensure receptive implementations and semantically separate the responsibilities of the assumption and guarantees instead of independent design.Their definition based on predefined partitioning of variables also limits the application of contracts as it cannot apply to components without rigorous input-output ports such as ones with bidirectional ports.Furthermore, being u-receptive requires the guarantees to include behaviors rejected by its assumptions, and thus the guarantees have larger behavior set sizes and contain redundant information.Therefore, taking the notion of receptiveness for behaviors as the foundation, our work defines receptiveness for contracts which does not contain redundant information by requiring receptiveness only for the behaviors accepted by assumptions.We show that our proposed receptive contracts ensure independent design and it does not rely on predefined partitioning of controlled and uncontrolled variables.

III. THE VACUOUS IMPLEMENTATION PROBLEM
As introduced before, the empty sets of behaviors could be problematic in the set-based definition of contracts.Given a by definition an implementation of C.However, this implementation is not compatible with the targeted environment A. We call such an implementation a "vacuous implementation" of the contract.We also define a "strict implementation" of the contract C as an implementation During the design process, we should avoid vacuous implementations and guarantee strict implementations.However, the refinement of contracts results in smaller acceptable behavior sets, and thus we may lose all strict implementations for the  A , G ) such that the acceptable behavior set of the refined contract and the original assumption set are disjoint, as illustrated in Fig. 2. All implementations M of the contract C are vacuous implementations since In this section, we first provide a motivating example of the vacuous implementation problem in the independent design and then formulate the requirements to avoid the problem.

A. Motivating Example
Fig. 3 shows an example that the refinement of contracts results in vacuous implementations.Let the system contract be C s = (A s , G s ) = (x ≥ 2, y = 4x), and two contracts be ) as its subsystems whose composition refines the system contract.All contracts are defined on the variable set V s = {x, y, z}.The two subsystem contracts are then sent to different suppliers for independent development.If the supplier for C 1 refines the contract as during the design process, the composition of C 1 and C 2 remains a refinement for the system-level contracts.However, all implementations of the composition are vacuous implementations for C s , as shown in the following derivation: where M 1 is any implementation for C 1 and M 2 denotes any implementation for C 2 .
The example shows that the refinement can result in the vacuous implementation problem during independent design.Therefore, we hope to restrict the refinement to guarantee strict implementations, and the vacuous implementation problem can avoid the problem in independent development as long as all suppliers follow the restriction.In the next part, we formulate the requirement to avoid vacuous implementations and develop a restriction based on the requirement.

B. Requirement for Independent Design
We define contract replaceability as the requirement to guarantee strict implementation: C 2 and share the same variable set V C and assumption variable set V A .We say that C 1 is replaceable by C 2 , or that C 2 replaces C 1 , if the following condition is satisfied: Contract replaceability requires a projected behavior e in the assumption set A 1 such that the intersection of the guarantee set and the behavior projected back to the entire variable set V C is not an empty set.As a result, a behavior with the assignments of the assumption variables satisfying A 1 , the targeted environment, can be found in G 2 , the refined guarantee.A binary relation called the contract replaceability relation is defined as the set containing all contract pairs Contract replaceability ensures that the strict implementations for the original contracts can be found using the refined contract, summarized in Theorem 1:

be saturated contracts over the same variable set V C and assumption variable set
Proof.We prove Theorem 1 by showing that M 2 ∩ A 1 is not an empty set: where the equality is by the definition of refinement that A 1 ⊆ A 2 , and the inequality is by the definition of contract replaceability.Therefore, M 2 ∩A 1 is a superset of a non-empty set, which means M 2 ∩A 1 is not an empty set and thus a strict implementation for C 1 .
As a result, once the system contract is replaceable by the refined contract, we can find a strict implementation for the system contract using the refined contract.
However, we need the assumption set from the system contract to ensure contract replaceability.In independent design, the supplier does not obtain the system contract but relies on a refined contract.Intuitively, we can require that the supplier guarantees contract replaceability for the refined contract instead of the system contract.Unfortunately, the contract replaceability relation is not transitive.A contract replacing the refined contract is not guaranteed to replace the system contract, as shown in the following example: We can see that C 2 replaces C 1 , and that C 3 replaces C 2 .However, C 3 does not replace C 1 as To address the problem, a transitive relation that guarantees strict implementation is required.Thus, we propose strong replaceability: C 2 and share the same variable set V C and assumption variable set V A .We say that C 1 is strongly replaceable by C 2 , or C 2 strongly replaces C 1 , if the following condition is satisfied: Strong replaceability requires that for all projected behaviors e in the assumption set A 1 , the intersection of the guarantee set and the behavior projected back to the entire variable set V C1 is not an empty set.As a result, for each assignment of the assumption variables satisfying A 1 , we can always find a satisfying behavior in G 2 .A binary relation called the strong replaceability relation is defined as the set containing all contract pairs (C 1 , C 2 ) such that C 1 strongly replaces C 2 .The difference between replaceability and strong replaceability is the quantification of the projected behavior.
We can show that the strong replaceability relation is transitive: , and C 3 = (A 3 , G 3 ) be saturated contracts over the same variable set V C and assumption variable set Proof.Since C 3 strongly replaces C 2 , by the definition of strong replaceability: And A 1 ⊆ A 2 by the definition of contract refinement, so their projected behavior sets also hold the subset relation: , and thus e 1 satisfies the qualification for (1): By the definition of strong replaceability, C 3 strongly replaces C 1 .
Combining Theorem 1 and Proposition 1, we conclude that strong replaceability guarantees strict implementations during independent design in Theorem 2

same variable set V C and assumption variable set
Therefore, we propose strong replaceability as the restriction for suppliers to perform contract refinement.As long as all the suppliers follow the restriction to ensure strong replaceability, strict implementations for the system contracts can be found by A n ∩ G n .

IV. RECEPTIVE CONTRACTS
We have formulated strong replaceability as a restriction to ensure strict implementations in independent design.However, the problem that the conventional operations in assumeguarantee contracts cannot ensure strict implementations is worth exploring.In this section, we propose contract receptiveness as a constraint for assume-guarantee contracts so that any operations in independent design under the constraint ensure strict implementations.We will show that the receptive contract guarantees strong replaceability for refinement in Section V and cascade composition in Section VI.
Contract receptiveness is defined as follows: satisfying the following condition: A receptive contract requires that every assignment to the assumption variable set allowed by the assumption set corresponds to at least a behavior in the guarantee set.Fig. 4 illustrates the concept of the receptive contract.The areas between the dashed line represent all the assumption set assignments, Π V A (A) Each area in the receptive contract, as shown in Fig. 4 (a), must contain a behavior in G, while some areas in a non-receptive contract, as shown in Fig. 4 (b), do not contain any behavior in G.
Example 2. The contract C 1 in Example 1 is a receptive contract while the contracts C 2 and C 3 are not receptive contracts.To check the receptiveness of C 1 , we first find the assumption set assignments Then we check the receptiveness of the contracts C 2 and C 3 in Example 1, The assignments of the assumption variable allowed by C 2 is {x | x ≥ −2}.However, as the guarantee set requires x ≤ 4, any behavior with assignments of the assumption variable being x > 4 is not in the guarantee set.Similarly, for C 3 , the guarantee set requires x ≤ −1, and thus any behavior with assignments of the assumption variable being x > −1 is not in the guarantee set.Therefore, the two contracts are not receptive.

V. REFINEMENT WITH RECEPTIVE CONTRACTS
In this section, we show that the proposed receptive contracts guarantee strong replaceability for refinement during independent design and allow the suppliers to discover design faults in the specifications.
Theorem 3 states that receptive contracts guarantee strong replaceability in the refinement operation: Proof.We prove Theorem 3 by converting the condition for receptiveness to the condition for strong replaceability: As C 2 is receptive, using the definition for the receptive contract we get:

By the definition of contract refinement,
Combining the above results, we get Therefore, C 2 strongly replaces C 1 by the definition of strong replaceability.
Receptive contracts guarantee strong replaceability not only for the abstract contracts before refinement but also for the system contract.To see this, we first show that a receptive refined contract implies that its abstract contract is also receptive: be saturated contracts over the same variable set V C and assumption variable set Proof.During the proof in Theorem 3, we have derived the following: Therefore, C 1 is a receptive contract by Definition 3.
Strong replaceability for the system contracts, summarized in Theorem 4, can thus be derived by combining Proposition 2 and Theorem 3: Proof.We prove Theorem 4 by induction.When n = 2, the statement holds by Theorem 3. Assume that the statement holds for n = k.When n = k+1, C k+1 strongly replaces C 2 by the assumption.C 2 is a receptive contract as C k+1 is a receptive contract by Proposition 2. Applying Theorem 3 on C 2 and C 1 , C 2 strongly replaces C 1 .Therefore, by the transitivity of strong replaceability in Proposition 1, C k+1 strongly replaces C 1 .By mathematical induction, Theorem 4 holds for any n ≥ 2.
Furthermore, Theorem 4 implies that the suppliers can discover faults in the specification.We can impose receptiveness as a constraint on the assume-guarantee contract.The suppliers can rest assured that strong replaceability holds as long as the received abstract contract is receptive.In contrast, if the suppliers receive a non-receptive abstract contract, some faults must have occurred before the abstract contract was generated.Accordingly, the supplier can alert the specification provider to check for faults during the design process.

VI. CASCADE COMPOSITION WITH RECEPTIVE CONTRACTS
We have presented requirements for independent design under the refinement operations.However, in contract-based design, an abstract contract can be decomposed into several contracts whose composition refines the abstract contract.The decomposition of a contract is analogous to decomposing a system into several subsystems.Each subsystem follows the decomposed contracts.If a supplier receives one of the subsystem contracts and refines the subsystem contract, the supplier cannot check the strong replaceability of the composition without the other subsystem contracts.In this section, we discuss strong replaceability in composition using receptive contracts.
A composition is either a cascade composition or a feedback composition, depending on the topology of the subsystems.A cascade composition has subsystem order such that the assumption variable set of each subsystem only connects to the variables from the assumption variable set of the environment or the variables set from the preceding subsystems.We will use the subscript s to denote the system contract and numbers as subscripts to denote the order for the subsystem in a cascade composition.For example, let a system C s be a cascade composition of two subsystem contracts C 1 C 2 .Then C 1 precedes C 2 , and thus by the definition of cascade composition, V A1 must be a subset of V As .A feedback composition is any composition that is not a cascade composition, meaning that subsystem order cannot be defined.
In this section, we discuss the following problem: Let the system contract be All the behavior sets are defined in the variable set V Cs .We will show that the composition C 1 C 2 strongly replaces the system contract C s = (A s , G s ).For the feedback composition, we will present an example showing that the composition of the refined receptive contracts does not ensure strong replaceability.More constraints are thus required for general composition.We leave these additional constraints for feedback composition as future work.
We develop two lemmas to show strong replaceability of the cascade composition by receptive contracts.The first lemma, summarized in Lemma 1, states that any assignments to the assumption variable set of the system contract must satisfy the assumption of the first contracts.
Proof.Assume that e is a counterexample of Lemma 1 such that e ∈ Π V As (A s ) and Π V A 1 (e) / ∈ Π V A 1 (A 1 ).We want show that e / ∈ Π V As (A s ), and thus the assumption leads to a contradiction.First, we show that Π V Cs (e) ⊆ A 1 and , we can project the two sides back to (2) Then we discuss whether e can satisfy the assumption set of the second contract in two cases.The first case is a) Case 1: Combining ( 2) and (3), we get: Therefore, Π V Cs (e) ⊆ A s , and thus e / ∈ Π V As (A s ), which contradicts our assumption that e is a counterexample.b) Case 2: Considering the behavior e 4 = Π V Cs (e 3 ) ∩ Π V Cs (e), we can get e 4 ∈ Π V Cs (e) and e 4 ∈ Π V Cs (e 3 ).Also, e 4 ∈ Π V Cs (e) implies e 4 ∈ A 1 ⊆ G 1 .
Therefore, we can get: As a result, we can derive that e 4 is not a behavior in A s : Therefore, e 4 ∈ A s , and thus e = Π V As (e 4 ) / ∈ Π V As (A s ), which contradicts the assumption that e is a counterexample.
As both cases lead to contradictions, Lemma 1 is thus proved.
The other lemma, as shown in Lemma 2, states that the behaviors of the first contract satisfy the assumption of the second contract if the behaviors meet the assumption of the system contract.behaviors generated by G 1 must be in the assumption set of the second contract.
The lemma is proved by contradiction that if . Therefore, we can derive the following: Similar to the proof for Lemma 1, we can show that Π V Cs (e 1 ) ∩ Π V Cs (e 2 ) ⊆ A s : Therefore, Π V Cs (e 1 ) ⊆ A s , and thus e 1 / ∈ Π V As (A s ) contradicts the assumption.
With Lemmas 1 and 2, we conclude that any refinement to the receptive contracts ensures strong replaceability, as shown in Theorem 5: , and thus: By Lemma 2, e 2 and e satisfies Π and thus: Considering the behavior Π V Cs (e) ∩ Π V Cs (e 2 ) ∩ Π V Cs (e 3 ) and combining the results in ( 4) and ( 5), we get: , the condition for strong replaceability is satisfied.Therefore, C 1 C 2 strongly replaces C s .
Finally, we show an example of a feedback composition using receptive contracts that contains only vacuous implementations after refinement: Example 3. Let C s be the system contract, C 1 and C 2 be the subsystem contracts, and C 1 be the refined contract for C 1 : , and thus the only implementation is a vacuous implementation M 1 = ∅, even though the refined contract is a receptive contract.
We believe that additional constraints are needed for feedback composition such that the strong replaceability of any composition is ensured.The constraints for the feedback composition will be material for future work.

VII. DISCUSSION
In this section, we discuss the impacts of the discovery and proposed concept on the contract-based design process, and thus the need for the development of new algorithms and tools for supporting contract-based design.

A. Design Faults in Refinement
The vacuous implementation problem should be regarded as a type of design fault, which might be caused by the designer or problems in the automation tools to generate refined contracts not satisfying the replaceability relation.The replaceability relation is crucial for the refinement process to guarantee the compatibility of its subsystems and thus avoid vacuous implementations after system integration.Only verifying the refinement relation cannot capture this type of design fault.Therefore, existing contract-based design methodologies [19], [25] that propose using refinement in the design process, should include a stage for verifying the replaceability of the top-level specification.The transitive strong replaceability breaks down the problem of verifying the replaceability of the top-level specification into verifying the strong replaceability between each refinement step and thus can be applied in the independent design paradigm.If the design faults are not captured in this early stage of design, the vacuous implementation would result in huge costs and design time overhead.

B. Applying Receptive Contracts
In Section IV-VI, we have shown that receptive contracts guarantee strong replaceability in cascade composition and pure contract refinement.The theory indicates that using receptive contracts can further simplify the process of verifying the replaceability relation.As long as the system does not contain feedback composition, receptive subsystem contracts guarantee the replaceability of the refined systems to the top-level specifications.In many application fields, the specifications should be receptive by their definitions, such as controller design and sequential programs.The inputs and outputs are explicitly defined for every system in these fields.Therefore, verifying receptive contracts can serve two roles at the same time, one is verifying the design faults, and the other is maintaining the semantics of the components, as it is meaningless for a controller or a program method to have no outputs for any allowable inputs.

C. The Need for Development of New Algorithms and Tools
With the proposed theory, we suggest the development of new algorithms and tools to facilitate the contract-based design.Existing contract tools and algorithms [5], [9] do not include the functionality to verify the replaceability relation, and thus are unable to detect the design faults of vacuous implementation.The universal quantification in the strong replaceability and receptiveness is challenging for algorithm development as its decidability depends on the representations of contracts.For example, the Presburger arithmetic is decidable while it becomes undecidable if multiplication is involved [18].Therefore, research on tools and algorithms for different representations of contracts is required to prevent design faults and enable independent design using contracts.

VIII. CONCLUSION
We identified the vacuous implementation problem using assume-guarantee contracts under the independent design paradigm.We first explored the notion of contract replaceability.This notion was shown to be the requirement to ensure strict implementations, but it is not transitive, thus limiting its applicability in independent design.The stricter notion of strong replaceability also ensures strict implementations and is transitive, thus fitting the independent design paradigm.We then proposed the notion of contract receptiveness, which guarantees strong replaceability.Moreover, we showed that receptive contracts can be implemented independently and that the composition of their implementations will not be vacuous in the case of cascade composition.A supplier receiving a contract as the specification for implementation can check whether this contract is receptive.If so, the supplier knows in advance that it can proceed to develop an implementation and that this implementation will integrate correctly into the system integrator's design.Our areas of future work include finding constraints for feedback composition, developing tools to support independent design, and investigating the replaceability in different contract formalisms.

Fig. 3 :
Fig. 3: A motivating example that shows the vacuous implementation problem in contract refinement.All implementations based on the refined composition C 1 C 2 are vacuous implementations for C s .

Example 1 .
Consider the following three contracts C 1 , C 2 , and C 3 , where C 1 C 2 C 3 :

Fig. 4 :
Fig.4: Illustrations of a receptive contract and a non-receptive contract.(a) A receptive contract as all its areas separated by the dashed lines intersect with the guarantee set.(b) A nonreceptive contract as the area at the bottom of A does not intersect with the guarantee set.

Fig. 5 :
Fig. 5: Visualization of Lemma 1.Any behavior from the targeted assumption satisfies the assumption of C 1 .

Fig. 6
Fig.6illustrates the concept in Lemma 2. The projected assumption from the system contracts and all the corresponding

Fig. 6 :
Fig. 6: Visualization of Lemma 2. The combined behavior of any behavior from the targeted assumption and the corresponding behavior generated by C 1 satisfies the assumption of C 2 .