Early-Stage Resource Estimation from Functional Reliability Specification in Embedded Cyber-Physical Systems

05/03/2020 ∙ by Ginju V. George, et al. ∙ IIT Kharagpur 0

Reliability and fault tolerance are critical attributes of embedded cyber-physical systems that require a high safety-integrity level. For such systems, the use of formal functional safety specifications has been strongly advocated in most industrial safety standards, but reliability and fault tolerance have traditionally been treated as platform issues. We believe that addressing reliability and fault tolerance at the functional safety level widens the scope for resource optimization, targeting those functionalities that are safety-critical, rather than the entire platform. Moreover, for software based control functionalities, temporal redundancies have become just as important as replication of physical resources, and such redundancies can be modeled at the functional specification level. The ability to formally model functional reliability at a specification level enables early estimation of physical resources and computation bandwidth requirements. In this paper we propose, for the first time, a resource estimation methodology from a formal functional safety specification augmented by reliability annotations. The proposed reliability specification is overlaid on the safety-critical functional specification and our methodology extracts a constraint satisfaction problem for determining the optimal set of resources for meeting the reliability target for the safety-critical behaviors. We use SMT (Satisfiability Modulo Theories) / ILP (Integer Linear Programming) solvers at the back end to solve the optimization problem, and demonstrate the feasibility of our methodology on a Satellite Launch Vehicle Navigation, Guidance and Control (NGC) System.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 12

page 13

page 18

page 20

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

With increasing dependence of safety-critical systems on software and embedded computing, the notions of reliability and fault tolerance have undergone a paradigm shift. While the traditional approach for enhancing reliability in electro-mechanical systems is based on replication of physical components [21, 24, 32, 39, 3, 30], safety-critical embedded cyber-physical systems (CPS) must also consider reliability of software executions, packet drops in networks, priority inversion in scheduling of control tasks on shared processors, and many other factors which are attributed to the computational platform which executes the cyber part of the system [7, 28].

In the domain of cyber-physical systems, reliability targets of embedded control can be met through fault-tolerant design of the underlying platform and its structural components or through fault-tolerant deployment of the control software on the underlying platform. The former looks at the necessary resource requirements for providing reliable service at the platform level without specific focus on individual control components [4]. For example, while designing the CAN matrix for an automobile, we choose the topology and number of CAN segments depending on the overall loading of the buses and the reliability concerns thereof. On the other hand, fault-tolerant deployment of control focuses on individual control tasks [15]. For example, it includes replication of software tasks on multiple cores [38] and sometimes on the same core (temporal redundancy) [14, 26, 23, 25], or provides fault-tolerant scheduling frameworks that involve cloning of a sequence of tasks for layered task graphs [10, 37]. Fault-tolerant deployment also influences the choice of the platform and its components, but with respect to the reliability requirements for individual functional components.

The design cycle of cyber-physical systems begin with the preparation of a specification of the functionalities of the system. The use of formal specifications for defining the functional safety properties of such systems has been widely recommended in most industrial standards, including aeronautics (DO-178C), automotive (ISO 26262), industrial process automation (IEC 61508), nuclear (IEC 60880), railway (EN 50128) and space (ECSS-Q-ST-80C), specifically for those functionalities that require a high safety-integrity level. Although reliability and fault tolerance are as important attributes of the system design as functional correctness [6, 8, 9, 11, 27, 34], or performance attributes such as timing [1, 2, 12, 13, 33], power [17, 18] and security [22], formal specification of reliability, especially with respect to the critical functional safety properties has so far received very little attention. This is largely due to the perception that reliability and fault tolerance need to be addressed at the platform level, not at the functional level [20, 40]. On the other hand, we believe that with the increasing cost of electronics and software in cyber-physical systems, investment on reliability needs to be prioritized on the basis of the safety-criticality of the system’s functions.

This paper presents, for the first time, a methodology for overlaying formal functional safety specifications with reliability annotations and estimating the resource requirement from such extended specifications. A formal specification enables the designer to lay out the strategy for redundant computations and/or actuations [16] and obtain a formal reliability guarantee for the strategy using the proposed method of analysis. Moreover since this is done at the specification level, our methodology provides early estimates of the resource requirements, thereby facilitating design space exploration, where the tradeoff between reliability and resource requirements can be studied using the proposed methodology until an acceptable balance is achieved.

In particular, our previous work [16] explores various reliable strategies enabled by the given reliability specifications and converges on a strategy that maximizes the reliability – thereby also pointing out whether the specified reliability targets are attainable for every functionality of the design. In our level of abstraction, an action represents a discrete control event which is enabled by a logically defined pre-condition (sense) and achieves a logically specified consequent (outcome) when executed successfully on the underlying computational platform. We use the term action-strategy to denote possible sequences of actions that lead to some desired outcome. An action-strategy is admissible with respect to a reliability target, if the sequence and timing of actions involved in that strategy guarantees the desired outcome with the specified reliability guarantee. It may be noted that, more than one admissible action-strategies may exist for a functionality and every participating action (at any time instant) in an admissible strategy requires one processor (computing resource) to execute.

In the early stage of design of a complex, multi-component embedded control system, the designer must plan the sense-control-actuation steps for each control loop along with the corresponding timing constraints. The formal safety specification at this stage defines the necessary outcomes of the closed loop system as a timed function of the sensed input events. For example, we may be given a safety property of the form:

where sense_A is a sense event and outcome_B is the desired outcome which must happen within the time interval [1:10] following the sense event. Now in order to ensure that outcome_B does actually happen in that window of time, the control system must perform appropriate actions (called actuations).

Suppose we have an action, called action_C which can cause outcome_B, but the causality is not fully guaranteed. Suppose:

which means that action_C, if used, can cause outcome_B 80% of the time. Now suppose our reliability target for the above safety property is . If the sense event, sense_A, triggers one execution of the action, action_C, then the reliability with which outcome_B is guaranteed is only . Therefore, in order to achieve the target of , we must be prepared to repeat action_C more than once, either on different resources, or on the same resource but at different times. Moreover, all executions must be completed within the specified window of time, namely [1:10], following the event sense_A.

In a complex system, there can be many safety properties and therefore, many different actions may have to be repeated spatially and/or temporally to achieve the desired reliability. We provide a framework, where the system designer can overlay a chosen pattern of redundancy over the temporal fabric of the safety specification. For example, consider the following specification:

The above specification specifies that following a sense_A event, the action, action_C, will be executed in parallel at some time in the window [2:5], and will be again executed after units of time. It be noted that all three executions of action_C are constrained by time windows, but they can be executed in more than one way within the specified windows. A formal specification framework like this has two immediate advantages:

  1. We can verify whether the specified redundancy in the executions of the actions achieves the target reliability of the safety properties.

  2. Each possible schedules of the actions provides us an early estimate of the resource requirements. We can also find the schedule which has the optimal resource requirement. In a complex system, with many actions and replications, this is a non-trivial task and computationally beyond manual capacity.

It may also be noted that two admissible action-strategies with respect to two different reliability specifications may share some common actions. Given a set of admissible action-strategies with respect to various sensed-events, it is necessary to predict the amount of resources (processors) required in order to execute all of them in a worst-case scenario when all sensed-events, take place together. This estimation is non-trivial due to the sharing of actions and the redundancy provisions present in the strategies, and hence the choice of an appropriate admissible action-strategy with respect to every sensing is a key to reduce the number of resources. This paper presents a novel technique for selecting and grouping the set of admissible action-strategies attributed from various specifications with respect to different sensed-events, so that the number of resources needed in the worst case for executing the actions is minimized.

With the rapid growth in the number of features supported in modern appliances, the computing paradigm is shifting from a federated architecture where each feature runs on a dedicated processor to an integrated architecture where Electronic Control Units (ECUs) are shared among multiple features. While integrated architectures are able to reduce the costs of electronics and networking, the scheduling and fault tolerant deployment of control tasks has become more complex. We believe that having an early estimate of the resource requirements, as in the proposed approach, can help in taking rational decisions on the tradeoff between reliability and resource costs.

Our early work, presented in [16], introduces the formal framework for reliability specification. The problem of estimating resource requirements from such specifications is treated in this paper for the first time. The main contributions of this paper are as follows:

  • We extract all possible admissible reliability strategies from a given reliability specification, that meets the desired reliability target for a functional specification.

  • We formulate the resource optimization problem in terms of a constraint-satisfaction problem which can be solved using SMT / ILP solvers.

  • We have studied the proposed technique over test-cases from automotive domain and also shown the scalability of our approach over several experiments.

  • We illustrate the practicality of our proposed technique using a case-study (over Satellite Launch Vehicle Navigation, Guidance and Control (NGC) System) from avionics domain.

It is important to note that resource estimation is intricately related to the code volumes associated with the control tasks and their worst case execution times (WCET) on the chosen ECUs. In practice, the design of embedded systems is a process that goes through multiple generations of a product, and statistical knowledge about the execution times and the probability of their success in terms of providing the desired outcome are available from legacy data. Therefore early estimation of the tradeoff between functional reliability and resource requirements is feasible in practice, though not in established practice today.

The paper is organized as follows. Section 2 illustrates the preliminary concepts and the earlier works carried out to set up the premise for this work. In Section 3, we present the formal problem definition and methods to determine the optimal number of resources. The experimental results showing the efficacy of our proposed framework is given in Section 4. In Section 5, we demonstrate our proposed methodology using a practical case-study. Finally, Section 6 concludes the paper with a brief discussion on the ramifications of the proposed approach.

2 Background Work and Preliminaries

An embedded controller of a CPS comprises of three primary modules, namely Sensor, Controller and Actuator – which interacts with the Plant (or the environment) to perform desired behaviors. The sensor is responsible for sensing input scenarios from the plant (or the environment). The controller performs the control decision based on the sensed input. The actuator delivers actuation signals to the plant (or the environment). Some of the activities in CPS control may be implemented using software and the rest may be controlled via hardware. For example, sensing a scenario where the brake should be applied automatically, the computation of appropriate brake-pressure may be carried out using a software program. However, maintaining the same break-pressure for a certain amount of time is performed by a hardware-control. The resultant outcome while applying such actions is the application of the wheel-brakes and thereby reduction in the vehicle speed. We present a formal model for embedded CPS and such requirements in the following.

Figure 1 provides a schematic representation of the embedded CPS framework. Here, the events that are responsible for sensing inputs, actions (actuations) and outcome activities are termed as sensed-events (), action-events () and outcome-events (), respectively. While interacting with the plant model, the controller receives the sensed-events and compute appropriate actions/actuations to produce the desired outcome-events. The outcome of an action may take place after many control cycles and may also be durable over a period of time. Typically, the control software execution platform is responsible to compute appropriate actuations for the desired outcomes being enabled.

EI EA EO

Figure 1: Schematic Representation of the Embedded CPS Framework

The reliability of the CPS is governed by the fault-free execution from sensed to the outcome events. This intuitively means, after sensing an input scenario, how reliably an action (actuations) can be performed once the controller decision is undertaken properly. In this model, the reliability of the outcome activities are attributed from the unreliable computational platform where the action events are scheduled, computed and applied. To meet the desired reliability of the outcome behavior, the fine-grain control incorporates various physical redundancy attributes in the scheduled actions inside the control execution platform. It may be noted that the unreliability lies primarily in the execution of action-events (as per our model), though there can also be failures in the sensing and application of outcome activities or imperfections in message communications. However, this framework can be suitably extended to handle such uncertainties in other components of the embedded CPS framework.

From an abstract point of view, the activities of a CPS can be visualized in terms of sequence of events. The early-stage functional specification narrates the outcome-event based on a sensed scenario which is to be met with specific reliability targets. Such specifications describe the correctness requirements for a CPS. In addition to this, the meta-level action-strategy specifies the supervisory control orchestrated by the control software where the redundancies in actions are described for a sensed scenario. Such requirements are termed as CPS reliability specifications [16].

Now, let us revisit the formal model for such embedded CPS specifications as introduced in [16] using an elementary correctness requirement, , for the subsystem, , with a sense-event, , and an outcome-event, as follows:

It means that, whenever is sensed then the outcome-event is asserted within next to time-units111The formal expressions of the properties have syntactic (and semantic) similarity with SystemVerilog Assertions (SVA) [42].. Suppose, is the action-event responsible for producing the outcome . If the probability of success for given the successful execution of is expressed as, , then the current reliability () of the property, , is also . Since we have , so happens under the assumption of a perfect sense and action scenario222We assume that the control system senses perfectly (without any false positives or false negatives) and also generates appropriate actions based on the sensed-event., where both and .

At the design-level, the controller can leverage spatial and temporal redundancy provisions to improve the reliability of the outcome-events and thereby enhance the functional reliability of the design specifications. Figure 2(a) and Figure 2(b) show the schematic models where the spatial and temporal redundancy provisions are incorporated at the controller level. In the spacial redundancy model for a CPS control system, , there are parallel instances of the controller, namely and computational counterparts, . The controllers sense the same events () and produce the action-events (), respectively, at time . Each action-event goes into a possibly unreliable computational counterpart, , respectively. On the other hand, in the temporal redundancy model, number of re-executions are made by a single controller within the time-window from to . At time (), the controller, , senses same input-event, , and produces the action-event, . This action-event goes into the possibly unreliable computational counterparts, , and produces an output-event at . Finally, the outcome-event, , produces successful (correct) outcome if one of the outputs of (or ) produces correct result for both these cases333We assume a fail-silent model here, where failure in any outcome implies discontinuation of that outcome – thereby it will not interfere with other correct outcomes and can possibly be distinguished from these correct outcomes..

C1 C2 Cn M1 M2 Mn EI EC1(t) EC2(t) ECn(t) EO V

(a) Spatial Redundancy Model

t1 t2 tm C Mt1 Mt2 Mtm EI ECt1 ECt2 ECtm EO V

(b) Temporal Redundancy Model
Figure 2: Redundancy Models of an Embedded CPS Control (adopted from [16])

Such design-level redundancy provisions can be captured from the functional specification-level as well. For example, we can formally represent the spatial and temporal redundancies (as shown in Figure 2) using the properties, and , respectively, as follows:

Here, asserts that, whenever is sensed then the action-event is asserted parallelly in execution units (denoted by the construct) within next to time-units. Similarly, asserts that, whenever is sensed then the action-event is asserted times by multiple executions (denoted by the construct) within next to time-units. At this current setup, the reliability of the outcomes are also increased and these are represented as, and , respectively.

Let us present an example to explain such functional correctness and reliability specifications.

Example 1

Adaptive Cruise Control (ACC) supports features to – (a) maintain a minimum following interval to a lead vehicle in the same lane and (b) control the vehicle speed whenever any lead obstacle is present. Let us consider the functional requirements of ACC, which senses the proximity of any lead vehicle and a leading obstacle by the sense-events, and , respectively. The required action-events issued by the ACC controller for reducing throttle by and applying proper pressure in wheel-brakes are denoted as, and , respectively. The corresponding outcome-events are given as, and . It may be noted that a single time-unit delay is considered to be of ms in all the functional specifications mentioned below.

Now, consider the following two functional correctness requirements of ACC as follows:

  1. : As soon as a lead obstacle is sensed, then within a total of ms, the throttle is adjusted (reduced by ) followed by the application of wheel brakes after - ms. Formally, this property is expressed as:

  2. : Whenever a lead vehicle is sensed in a close proximity, then within a total of ms, the throttle is adjusted (reduced by ) followed by the application of wheel brakes after - ms. Formally, this property is expressed as:

Suppose, the desired reliability of the given correctness requirements be and for and , respectively. Here, the actions and are responsible for producing the outcome-events and , respectively. Suppose, the outcome-events are unreliable and their reliability values are given as:

Since the outcomes are unreliable, the ACC must issue the action-events with appropriate redundancy in order to meet the desired reliability target, as given by the following reliability specifications.

  1. : As soon as a lead obstacle is sensed, then the throttle-reduction action-event is scheduled in two processors parallelly within ms, followed by the brake-apply action-event which is also scheduled in two processors parallelly within next ms. Formally, this property is expressed as:

  2. : Whenever a lead vehicle is sensed in a close proximity, then the overall action of throttle-reduction applied successively twice, followed by brake-application in the next time-unit is re-executed twice within an overall time limit of ms. Formally, this property is expressed as:

Now, given the reliability specifications, and and assuming that the sensed-events ( and ) are present in Cycle-0, the reliability for the correctness specifications, and are calculated in Table 1 and Table 2, respectively, with respect to each action/control strategy444The method for formal reliability assessment is presented in [16] in details.. For example, the reliability computed from Option- in Table 1 is given as, , since there are spatial redundancy provisions for each action in with respect to the outcomes of . Similarly, the reliability computed from Option- in Table 2 is given as, , since there are ways to satisfy from the given action-strategy of .

Possible Action Events (Cycle-wise) Computed
Options Cycle-1 Cycle-2 Cycle-3 Cycle-4 Reliability
(1A)
(1B)
(1C)
(1D)
Table 1: Possible Options of Action-Events for
Possible Action Events (Cycle-wise) Computed
Options Cycle-1 Cycle-2 Cycle-3 Cycle-4 Cycle-5 Cycle-6 Reliability
(2A)
(2B)
(2C)
(2D)
(2E)
(2F)
Table 2: Possible Options of Action-Events for

The highlighted rows of Table 1 and Table 2 indicate the action-strategies that meet the desired reliability requirements for both properties of subsystem. We call all these strategies meeting the reliability targets as the admissible action-strategies.

3 Reliability-aware Resource Estimation

In this section, we formally present the problem of reliability-aware resource estimation and illustrate the detailed resource allocation procedure.

3.1 Formal Statement of the Problem

The problem of finding the optimal number of computing resources (processors) considering the simultaneous occurrences of a set of sensed-events is formally described as:

Given:

  1. A set of formal correctness and reliability properties of the system,

  2. Assigned reliability targets with respect to each correctness specification,

  3. The set of sensed-events that may occur simultaneously, and

  4. A set of admissible action-strategies corresponding to every sensed-event (derived from the corresponding reliability properties of the system).

Objective: To determine the appropriate choice of action-strategy with respect to every sensed-event so that the overall resource/processor requirement is minimized.

Assumptions:

  1. Same actions participating under two different action-strategies corresponding to different sensed-events can be executed together in the same processor.

  2. Execution of every action takes unit time (one cycle) in the processor.

  3. Within one action-strategy, the participating actions appear as disjunction-free.

Assumption-(i) prevents this resource optimization problem to have similar behavior as any conventional two-dimensional strip packing problems [31] and hence we cannot directly apply those solutions here. However, the solution space is determined by several possible choices of the action-strategy combinations attributing to the varied number of processors required. The following example illustrated this in details.

Example 2

Let us revisit Example 1 where we derive the admissible action-strategies for the two specifications of subsystem in the highlighted rows of Table 1 and Table 2.

Suppose, the sensed-events, and , occur simultaneously at Cycle-0. Then, Table 3 denotes possible execution options for the action-events combining the both the strategies. For example, if we try to ascertain Options with , then we need two processors in Cycle-1 to execute two parallel events among which one event of Option is shared/paired with the from Option .

Strategy Possible Executions of Action-Events (Cycle-wise) Resource
Comb. Cycle-1 Cycle-2 Cycle-3 Cycle-4 Cycle-5 Req.
1A+2A
1A+2B
1A+2D
1B+2A
1B+2B
1B+2D
1C+2A
1C+2B
1C+2D
1D+2A
1D+2B
1D+2D
Table 3: Possible Executions of Action-Events and Required Resources for Subsystem

Such action sharing helps us to reduce the number of processor requirements. We find that combination requires processors to execute the action strategies. Table 3 presents all the possible combinations and the required resources while executing each of these combinations of action strategies. It may be noted that, the minimum number of resources () is required when we perform the actions as per the Options and for both the properties. Hence, the next challenge is to bind the action-events with respect to Cycles so that the required resources are minimized.

3.2 Resource Estimation Procedure

The required number of resources can be computed from a set of admissible action-strategies (corresponding to sensed-events) derived from the reliability properties of a system, assuming that the corresponding set of sensed-events occur simultaneously. The minimum count of execution units depends on the optimal allocation of the actions to appropriate processor cores in every execution time/cycle so as to maximize the sharing of action executions. The entire problem can be modeled as a Constraint Satisfaction Problem (CSP) which can be solved by an SMT / ILP solver.

Figure 3 illustrates the primary steps in this framework. The steps that are involved here are primarily categorized in two broad parts, namely – 1. Parsing and Action Representation and 2. Constraint Generation.

Figure 3: Resource Estimation Framework

1. Parsing and Action Representation

From the reliability properties and the derived action-strategies, the first step is to identify relevant information of the action-event occurrences, their timing and redundancy related information so that the required constraints can be derived later. We present various stages of parsing and action representation as follows.

  1. Action Identification: This step identifies the set of action-events from reliability specifications. For reliability specifications having redundant actions, duplicate action-events are created.

  2. Time Prefix Determination: The time prefix of an action-event, extracted from the reliability specification, is typically given as either (fixed-time) or (time-range) where , the set of all non-negative integers. The lower and upper bound of the time prefixes are represented using a doublet, , for the fixed time prefix and a doublet, , for representing the variable time prefix. The redundancies are treated as follows:

    • In case of spatial redundancy (-times), all replicated actions (from to occurrences) have as the time-prefix.

    • In case of temporal redundancy (-times), let the time prefix for the first action in the first execution be extracted as . Then, the first action of () re-executed sequence can start earliest at and latest by 555 is computed from the reliability specification considering the given reliability target of the corresponding correctness property. Intuitively, this upper bound in time comes from the fact that delaying the start (beyond ) in re-executing the same sequence reduces the number of possible satisfaction of the correctness property and hence the specified reliability remains unmet (Literature [16] provides more details). – thereby having as the time-prefix. The time prefixes of the other actions are extracted from the specification and remain same across all their re-executions.

  3. Spatial Redundancy Factor Extraction: Action-events with spatial redundancy of are represented by associating each replication with a spatial redundancy factor from to . A default spatial redundancy factor of is assigned to action-events having no spatial redundancy.

  4. Timing Variable Creation: Timing variable represents the time of occurrence of an action-event. For every action-event identified from the reliability properties, unique timing variables are created for each occurrence (replicated or re-executed) of that action, which will be used to derive the constraints relating to the time of execution of these action-events.

  5. Linking Action-Events: For every action-event appearing in the reliability specification, the timing-related constraints will be generated either from the absolute time of its occurrence or in relative to the timing of its preceding event. Hence, we need to map each timing variable (corresponding to an action-event) to the timing variable of its preceding action – thereby aiding to the generation of timing constraints for action-event sequences with respect to an action-strategy. The first action-event in the reliability specification is not linked to any other events, since it depends only on the time of occurrence of the sensed-event. Hence, the timing variable corresponding to the first action-event has its linked variable as . For redundancies, the action-event links are done as follows:

    • In case of spatial redundancy (-times), all replicated actions (from to occurrences) are linked with the first occurrence of that action.

    • In case of temporal redundancy (-times), the first action in the re-execution () is linked with the first action in the re-execution.

These stages of parsing and action representation are illustrated in details through Example 3.

Example 3

Consider the reliability specifications, and , with their corresponding correctness specifications, and , as given in Example 1.

Action Time Pref. Sp.-Red. Factor Time Var. Link Var.
is computed from w.r.t. the reliability targets of
(a) Action-event Information Extracted for
Action Time Pref. Sp.-Red. Factor Time Var. Link Var.
(b) Action-event Information Extracted for
Table 4: Action-event Information extracted after Parsing and Action Representation Stages

Table 4(a) and Table 4(b) show the information extracted for these properties after parsing and action representation stages, assuming that the sensed-events, and , for the properties happen together at time .

2. Constraint Generation

Primarily, the set of generated constraints can be of the following two types – (i) timing-related constraints, and (ii) resource-related constraints. However, the detailed stages, needed to derive these constraints to be used by the CSP solver, are given below.

  1. Timing Constraint Generation: Given a reliability specification, , let the timing variable corresponding to an action, , be . It has the time-prefix and is linked with another action, , having the timing variable as (). Then, the timing constraints for are,

    (1)

    If , then the timing constraint is simplified as,

    (2)
  2. Timing Variable Grouping:

    Timing variable are grouped to enable resource minimization through its sharing. Variables corresponding to same action are grouped together and corresponding to every action, at least one group is formed. Given two reliability specifications, and , having a common action, , let the timing variables corresponding to , be and , respectively. Then, we can put and together forming one group, , i.e., . It may be noted that, all the timing variables belonging to one group, say , are associated with the same action-event, say , from different properties. Here, can also be the first occurrence of an action being replicated -times (spatial redundancy).

    Moreover, in case of spatial redundancy (say, action in is replicated -times), the timing variables, , corresponding to every replicated action ( to occurrence) forms a singleton group, i.e., . Now, if exists in another specification, , with spatial redundancy -times, then the grouping varies, depending on the relative values of and :

    • If , then .

    • If , then and singleton groups, .

  3. Resource Constraint Generation: Pairing of timing variables into groups helps us to generate resource constraints such that, if then the corresponding actions (say, from and from ) are same, i.e. . So, these actions can be executed once whenever possible – resulting in a reduction in the execution resources (processors). Let an action-event, executing at cycle-, be represented using the timing variable ; then the required resource due to the execution of only that action is given as,

    The number of resources required at - by the group of timing variables representing an action is denoted as,

    Suppose we are given with specifications, , , , . We choose all timing variables belonging to each () from the group,

    and create sub-groups of as,

    Now, the required resource count for each of these sub-groups, , is denoted as,

    The sub-group count indicates the number of coincident action-events belonging to the same specification (implied by temporal redundancy). Hence, we indicate the total number of resources required at - to execute the actions from these n sub-groups of as,

    Let all the timing variables corresponding to the action-event, , appear in groups, , , , . Then, we define,

    A pertinent point to note here is that, for a group, , if there is no temporal redundancy involved (in the specification) for the representative action of that group, then we find, and the required resources at - becomes, . Hence, the generated resource constraint for - is derived as follows:

    (3)
  4. Auxiliary Constraint Addition: Two types of auxiliary (additional) constraints are derived to make the constraint generation process complete. These are discussed below.

    • Admissibility Constraint: We have noticed in Section 2 that, among all the action-strategies that are generated from a reliability specification with respect to the given reliability target of its corresponding correctness property, there is a subset of action-strategies which are admissible. Let us assume that the last execution of an action-event can happen latest at - such that all action-strategies remain admissible. Then, we need to add a constraint with respect to the timing variable, , corresponding to the last executed action as,

    • Resource Limit Constraint: We start with a pessimistic bound on the number of resources required and gradually refine that limit. For a given choice of maximum number of resources, , these constraints are expressed as,

All these generated constraints can also be used in a constraint optimization tool/solver (like ILP solvers). There, we need to add the additional objective function providing the minimization or maximization requirement. Since we are minimizing the number of resources (processors) in this case, the objective function will be:

Example 4

Let us revisit Table 4 generated in Example 3 and derive the required set of constraints.

  • Timing Constraints: The timing constraints with respect to the property, , are derived as:

    Similarly, the timing constraints with respect to the property, , are derived as:

    Now, is extracted from the logical satisfaction of using subject to specific reliability targets.

  • Timing Variable Groups: The timing variables for each action-events is grouped as follows:

    Here, all the timing variables present in the groups and correspond to action-event and that are present in the groups and correspond to action-event.

  • Resource Constraints: The resource constraints are derived using Table 5 for each -. Finally, we produce the following constraints ():

    Groups
    Table 5: Resource Constraint Generation (for -)
  • Auxiliary Constraints: The admissibility constraint, here, restricts the last action-event, , to happen latest by -cycle, i.e. (Refer to Table 4 of Example 3 for admissible action-strategies). Hence, we add, .

    Suppose, we set the resource limits as , then the added constraints are as follows:

If we fed all the above constraints together in a SMT/ILP solver, then we find the following satisfiable valuation of the variables: