Budget reporting should provide breakdown for the customer to assess the risk areas and possible sources of non-compliance with the budget.
If margins are not met at a given milestone, the supplier justifies it and proposes workaround solution, or corrective actions, or deviations with respect to the RB, which permit to come back within the margins.
7.3.1 Load and real-time
The verification of load and real-time margins is typically based on a schedulability analysis (see 5.5.1 for detailed information).
The verification of the CPU load budget intends:
a. to verify that the definition of the allocated resources and margin to be reached is unambiguous.
b. at PDR to verify that the budget presented is based on the first level of design and it is the result of elementary value for each processing to be executed on the system. The elementary value of each processing is justified by analogy or by measurement performed on a prototype. To verify that the concurrent processing taken into account to define the budget and so the margin is a realistic worst case.
c. at CDR to verify that the budget presented is based on measurement of each processing. To verify that the budget is refined by introduction of interrupt and kernel impacts. To verify that the concurrent processing taken into account to define the budget and so the margin is a realistic worst case.
d. at QR to verify that the budget presented is based on a measurement collected during a dimensioning scenarios and performed on a representative environment. To verify that the budget is close to the budget computed with elementary values, else to verify that the disparity is commented/justified.
The verification of the deadlines and timing constraints:
a. at PDR (and to be confirmed w.r.t. the DDR), performs schedulability analysis with the elementary value of each processing and according to the timing requirements identified in the RB or TS. Each timing requirement which cannot verify the complete schedulability analysis is verified by a partial or adapted schedulability analysis focused on it. If a schedulability coefficient for an activity is superior to the specified margins, it would be commented – justifying the actions in risk reduction. This first status is used as software design input
b. at CDR, refines schedulability analysis with the elementary measurement of each processing and according to the timing requirements identified in the RB or TS, according to the design constraints (response time, blocking time, phasing, etc…). Each timing constraint which cannot be verified by the complete schedulability analysis is verified by a partial or adapted schedulability analysis focused on it. If a schedulability coefficient for an activity is superior to the specified margins, it would be commented – justifying the actions in risk reduction.
c. at QR, refines schedulability analysis with the consolidation of the elementary measurement of each processing based on measurement performed during validation campaign on a representative environment. If a schedulability coefficient for an activity is superior to the specified margins, it is highlighted and guaranteed as a maximum limit.
7.3.2 Memory margins
The memory is based on non-volatile memory (e.g. ROM, PROM, EEPROM, hard disk) and volatile memory (e.g. RAM, DRAM).
The non-volatile memory budget for dedicated software is based on its static analysis (code and constant size).
The volatile memory budget for dedicated software can be based on its static analysis (data and stack size) if no dynamic memory usage is implemented, or dynamic analysis in others cases. Generally, for flight software there is no dynamic memory mechanism implementation (state of the art).
If specific constraints exist on each of these areas, the associated margins are identified (e.g. paging, MMU, virtual memory).
The verification of the memory budget intends:
a. at PDR, to verify that the budget presented is based on representative criteria from comparable projects already completed (by analogy approach). In case of new and complex function, the budget is based on a prototype or by analogy / reuse.
b. at CDR and following milestones, to verify that the budget presented is based on compiled object files.
In addition, the verification of the volatile memory budget intends, at CDR and following milestones, to verify that the stack allocation has been analysed based on the call graph and pre-emption phenomena and that a margin for it is specified.
In case of dynamic memory mechanism implementation, the verification includes also:
a. that the scenario used to define the necessary memory budget is justified and correctly dimensioned.
b. that the budget is the result of an analytic model and/or the result of a measurement on a specific test.
This memory budget includes aspects related to the compilation environment, the assumed code expansion factors (and the references for those numbers, including the project’s definition for Line of Code used), the effects of compiler settings (e.g. for optimisation, runtime checks, setting of the operating system kernel, runtime system and/or Board Support Package, …).
NOTE The budgets related to sizing of stacks, buffers, FIFOs are verified by the Supplier (in particular for robustness), but are potentially not subject to margin specification by the customer, except if future expansion is expected. The Customer should anyhow check if related requirements are necessary (e.g. for payload data management).
7.3.3 Numerical accuracy budget management
The supplier analyses for any (critical) function, that the selected (floating-point) format fits the required accuracy of the algorithms, including the effects of repetitive calculations and calculations with extremely small or deviating numbers.
The verification of the accuracy is usually based on the fact that the results of a reference scenario on the system modelling tool (running the algorithms that requires accuracy), and on the software target, remains in an acceptable difference. This can be assessed using absolute and/or relative differences; interval arithmetic can also help to determine what an acceptable difference is.
For analogue-to-digital and digital-to-analogue interfaces, the choice of the converter must fit the required signal resolution. If the software does not use the full resolution provided by the hardware, then the software supplier should analyse if the software resolution fits the requirements for the signal processing.
The verification intends:
a. at PDR, to verify that the (numerical) accuracy requirements are clearly specified in the RB and TS b. at CDR, to verify that the numerical accuracy requirement is reached according to the data type used and propagation effects. This verification is based on analytic analysis or a measurement performed on a representative numerical environment.
7.3.4 Interface timing budget management
The customer is responsible for establishing interface budgets. He may involve the supplier to optimise the interface requirements.
Interfaces determine, to a large degree, the system architecture. Hence the interfaces are usually defined in the early project phases. However, in those phases it is often not possible to assess all timing restrictions. It is therefore good practice to design the interface system such that margins and blocking are not critical to the design, in order to avoid costly changes to the architecture.
Changes to the architecture should not be excluded a priori. However, the customer, being responsible for the specified budgets, should show awareness of the potentially dramatic impact of architectural changes, by carefully re-assessing the specified budget values in those cases.
Interface timing budget management should be performed per subsystem interface, i.e. each interfacing system should be considered separately. Subsequently, the overall budget should be determined.
The budget per interface should include at least:
a. Nominal latency (no collision, error), per subsystem b. Maximum latency (collision, no error), per subsystem c. Error and reconfiguration handling, including uncertainty
d. Blocking behaviour, and reference to the tasks affected by the blocking
The budget reporting is the supplier’s task. It should provide sufficient insight and evidence for the customer to assess the feasibility of both the interface design and the overall architecture, in support of the computer processing budget management. This interface timing budget is used to compute the WCET (see section 7.2.2).