Causa Directa 2: Producción y ocupación ineficiente e insostenible del suelo

design, and schedulability analysis. They are just described in 7.4.3.1.5.

7.2 Software technical budget and margin philosophy definition

7.2.1 Introduction

The software product margins apply in particular to:

a. load and real-time figures including:

1. CPU load,

2. deadline for a processing with constraints (e.g. period, rendez-vous, reaction constraint, timing accuracy constraint);

b. memory capacity;

c. numerical accuracy;

d. external (including hardware) interface/event synchronisation and timing.

Margins definitions are agreed between the customer and the supplier. Guidance on margin definition is given in this section. Margin definition and management are likely to raise more attention for embedded or real-time software, as it is more difficult to extend the hardware resources, or to access to the system once launched. Hardware on the ground can be scaled up vertically and horizontally.

However, ground software may face other concerns at system level, e.g. in terms of ergonomics (for instance response time), network load, the definition of the environment such as the version of the hardware and software, which are not addressed here.

In order to allow the Supplier to manage the margins in an appropriate way (e.g. design flexibility), they should be defined by the Customer in the context of their need, e.g. for already known growth capability, or for risk reduction.

In particular, the margin philosophy should be specified in such a way that it does not over-specify the design, unless the customer has explicit requirements regarding the software architecture, scheduling and interfacing.

Criteria for the selection of all the margins can be:

a. The processor module capability. The processing budget management and reporting presume that basic hardware choices, such as processor type, clock frequency, wait-states have been made and clearly described.

b. Equipment, communication and performance aspects, e.g. buses, protocols, acceptable errors, capacity bus usage by other sources.

c. System design which is derived in timing constraints (e.g. constraints on state transitions, especially when recovery from a faulty state is concerned)

d. Expected future changes in the requirements baseline (e.g. due to iterations, requirements on reprogramming of the system during operational use, required budget for temporary copies of software images)

e. Expected phasing/versioning of the software development and its impact on produced code and CPU load

f. Accuracy aspects, such as conversion to/from analogue signals, and accuracy of timing signals g. Allocation of responsibilities regarding the characteristics of Service Access Point interfaces, if

not handled by one contractual party.

Reuse of existing software and software maturity (level of uncertainty on the figures) are also criteria in particular during the early phases where the figures are estimated

7.2.2 Load and real-time

7.2.2.1 Schedulability analysis

For load and real-time characteristics, information about schedulability analysis is given in section 7.5.2. Schedulability analysis demonstrates different real-time constraints such that all tasks meet their deadline.

The schedulability analysis uses (among others) the following two inputs:

a. the task worst case execution time (estimated in the beginning of the life cycle, measured later on)

b. the occurrence of events. For example, all events may be released at the same time, or phasing could be introduced between events.

7.2.2.2 Theoretical worst case and operational scenario

The worst case execution time of a function, task or software is widely understood as the theoretical worst case, either measured, or estimated or derived from code analysis techniques.

Alternatively, the notion of worst case can be refined functionally-wise, by selecting (realistic) operational scenarios (nominal or degraded, per mission phases or modes) that maximizes the execution time of each function (operational worst case).

The former (theoretical worst case) is more pessimistic than the latter (operational worst case), which is based on operational scenario.

The theoretical worst case is established on the basis of a discussion between customer (or system level) and supplier (or software level). The context of the occurrence of this worst case can be more or less critical, more or less realistic, more or less likely to happen. For example, CPU utilisation may go over 100 % in case of simultaneous occurrence of failures, or maximum frequency of all telemetry, which are generally not the system level assumptions.

In this context, the use of operational scenarios to derive an operational worst case and realistic operational sequences are a mitigation of the theoretical worst case (see Figure 7-1), as the difference between the two times could be substantial. It is nevertheless interesting to know the theoretical worst case, because it allows understanding the conditions when it can happen and to relate to the operational context.

NOTE ECSS-E-ST-40C clause 5.2.3.2 requires the customer to define representative scenarios.

Figure 7-1: Mitigation of theoretical worst case with operational scenarios.

7.2.2.3 Margins

Margins can therefore be proposed:

a. per task in isolation, by provision of a margin of execution time (margin_WCET)

b. per task in context, by provision of a growth capacity before it reaches its deadline (margin_slack),

c. globally, by provision of a growth capacity before the CPU saturation (margin_utilisation).

TASK WORST CASE

EXECUTION TIME OCCURENCE OF

EVENTS Schedulability

analysis

theoretical worst case

operational worst case

all events released simultaneously

operational sequence

operational scenarios

d fi fi

input input

The margins can be based on either theoretical worst case or operational worst case.

1) Margins can be defined on the deadline of a particular task taken in isolation using its Worst Case Execution Time:

margin_WCET(i) = [deadline(i) - WCET(i) ] / deadline(i)

This can be used to force a margin on the estimation of the WCET if the customer needs to have confidence on the estimated execution time, even if WCETs are already pessimistic in nature. In addition, this does not account for the context of execution of the task (i.e. the interference by higher-priority tasks). The only useful use of this margin is to understand the time window during which the task of interest completes its execution before its relative deadline occurs.

Typical values of this margin should be maximum 10% at PDR where the WCET is estimated, and then they should not be required later on.

The margin_WCET is generally based on the (theoretical) worst case execution time, because the focus is typically put on the execution time of the particular algorithm implemented in the task that is assessed against the envisaged deadline.

2) To take into account the context of execution of the task, a margin on the slack time can be defined.

The slack time is based on the response time of the task, i.e. the time after which it actually completes its execution in the worst-case scenario, taking into account all the potential pre-emptions by higher-priority tasks, the blocking time due to the access to protected objects, the execution time of interrupt handlers, and interference by mechanisms of the RTOS / real-time kernel.

response_time(i) = WCET(i) + interference(i) + blocking_time(i) slack_time(i) = deadline(i) - response_time(i)

margin_slack(i) = slack_time(i) / deadline(i)

Typical value of this margin very much depends on the nature of the task. Customer may wish to ensure computation margin to a particular computational-intensive control loop with short deadline, or instead to minimize margin to a background task. It is likely difficult to define a global margin such as 10% for all tasks. This could be a target at PDR, but should be refined later on.

The margin_slack uses the response time computed by the schedulability analysis, therefore based on the theoretical worst case (execution time and events). If the result is found pessimistic, the reasons are analysed, and the operational scenarios are used to assess the extent to which the operational assumptions are valid.

3) The theoretical CPU utilisation given by the schedulability analysis (in the absence of memory cache) is:

WCET(i)

U= Σi --- T(i)

where :

WCET(i) is the worst case execution time of the task i (estimated in the early phase, measured at the end of the project)

T(i) is the period of the task i if this task is periodic, or the Minimum Inter-Arrival Time (MIAT) of the event triggering the task if it is sporadic.

The CPU utilisation of a schedulable system is less than or equal to 1 (this is a necessary condition, but not sufficient to declare the system as schedulable).

The margin is:

margin_utilisation = 1 - U expressed in percentage

As said in ECSS-E-ST-40C, typical values of this margin are 50% [PDR], 35% [DDR/TRR] and 25%

[CDR and after].

The margin_utilisation uses execution time. Therefore, it is based on the theoretical worst case execution time. If the result is found pessimistic, the reasons are analysed, and the operational scenarios are used to assess the extent to which the operational assumptions are valid.

In addition, it is handy to assess the margin_utilisation by measuring the execution time of the background task (the task in which the software is idle). However, the time during which it is measured must be longer than the largest period or Mean Inter Arrival Time (MIAT) of the system.

7.2.3 Memory capacity

For memory capacity, the margin is defined as follow:

margin_memory = free size / total size

As said in ECSS-E-ST-40C, typical values of this margin are 50% [PDR], 40% [DDR/TRR], 35% [CDR]

and 25% [QR, AR].

7.2.4 Numerical Accuracy

For numerical accuracy, today’s processing systems use standardised integer and floating point processors (e.g. IEEE-Std-754-1985) in relation to specific data path widths, therefore the accuracy of both integer and floating-point calculations is known by these provisions.

The customer should clearly define all accuracy requirements and constraints, at least at system level (e.g. pointing requirements). The software supplier should derive the related numerical accuracy requirements, and manage them as per the ECSS-Q-ST-80C requirements 7.1.7.

When the algorithm is modelled at system level (e.g. Attitude and Orbit Control), the floating point representation and the mathematical library used on the target processor is introduced in the system modelling tools.

7.2.5 Interface timing budget

For interface timing budget, as a minimum, the following elements should be considered:

a. latency of interrogated subsystems (incl. error) b. latency of (bus) interfaces (incl. collision, bus error) c. interface reconfiguration

d. hardware driver characteristics e. software driver characteristics

f. This interface timing budget is used to compute the WCET (see section 7.2.2).