Descripción de la participación en los proyectos de Honduras

5.8.3.9 Evaluation of validation: complementary system level validation

-

5.8.3.10 Verification of software documentation

-

5.8.3.11 Schedulability analysis for real-time software

Schedulability analysis is discussed in 7.5.

5.8.3.12 Technical budget management

See also 7.3.

5.8.3.13 Behaviour modelling verification

NOTE Model based engineering is discussed in 6.3.

The ECSS-E-ST-40C requirement 5.8.3.13 requires the verification of the behavioural model. The following topics should be verified to anticipate the correct behaviour of the final SW product, during different steps of the life cycle:

a. the software dynamic aspects are well defined at design level: each function is properly described (e.g. with finite state machines or Statecharts), the way the different services are used (e.g. frequencies, task context, call order / dependencies, external activations by interrupts…).

Sequence diagrams / time lines is an efficiency way to show the dynamic behaviour of the services and the interactions between them;

b. the proposed design provides SW behavioural observability and debug features (e.g. time stamping of tasks starting and ending, semaphores changing);

c. the software design is safe and robust, in particular with regard to the external error propagation (e.g. defensive design, implementation analysis, test coverage).

5.9 Software operation process 5.9.1 Overview

5.9.1.1 Introduction

The purpose of this section is to explain the process related to the operation of space software. The following types of software are covered:

a. Flight software embedded in non-accessible space objects

b. Flight software embedded in serviceable vehicles which could be accessed at least in a limited way, through a human machine interface

c. Ground software which can be accessed at any time

All 3 categories of software are operated by the entity combining operations organizations and associated ground systems for which ECSS-E-ST-70C is applicable. For bullet a) flight software the software operation process described in ECSS-E-ST-40C (chapter 5.9) is to be considered in a wider scope of space vehicle operation.

The software operation process is linked together with the software maintenance process.

It covers the following activities (as far as applicable for a space project):

a. Operational management encompasses activities like:

1. managing and coordination of Ground Segment service requirements, 2. provision and support for all mission activities,

3. coordination of Missions operations management and Engineering, 4. management guidance,

5. conflicts resolution, and

6. on console during critical phases.

b. Operational planning involving producing the procedures for operating the product, training operators and users, operational testing, problem reporting, system operation and user support.

This encompasses tasks like

1. planning of Ground Segment resources for all preparation activities and mission activities (also with other projects and missions where applicable) with respect to Ground Segment usage,

2. technical and operational inputs for Simulation and Mission Timeline, 3. review of Mission Requirements Documentation,

4. resources scheduling / conflict resolution for all activities, 5. resource usage tracking,

6. Ground Communications Schedule generation, 7. IGS Work Plan generation,

8. Coordination of all participating facilities for On-board System and PL operation,

9. Preparation of Ground Segment operations (including simulation and testing activities), and

10. Voice Loop Management.

c. Operational testing of new releases: the software product is released for operational use when the operational testing criteria have been satisfied, in accordance with the operational plan.

NOTE The team responsible for software maintenance process is not always in a position to carry out operational testing, since this cannot be done without the operational environment and possibly specific operations expertise.

d. User support, implemented in practice using the organisation set up for the software maintenance process, including

1. assistance and consultation to the users as requested, 2. provision of workaround solutions,

3. advise on software use and documentation, and

4. handling user requests for software maintenance, including recording problem reports.

These activities are undertaken by the “System Maintainer” and the “System Operator”

(administration part of the role): these two roles are attributed to a SOS entity in the standard. The SOS entity is a link between the system operator and the software maintainer team. The SOS entity assumes a coordinator role during operations.

The phasing and management of the operations process is determined by the system level requirement to operate the software product at a given time, i.e. it is not always connected to overall project Phase E. Operations engineering can start earlier or later than the phase E. In principle, operations engineering starts at the time of the operational readiness review (ORR, see ECSS-E-ST-70C). In practice, it starts earlier, because ground segment software products are in extensive use to qualify the ground segment and interfaces to the space segment well before operations occur. On the other hand some software may not be operational until long after launch, for example in a deep-space mission.

5.9.1.2 Incident Management

During operation of the software, incidents can occur. An incident is an unplanned interruption to a software system or service, or a reduction in quality of a system or service. Failure of a configuration item that has not yet impacted a service is also classed as an incident.

The purpose of incident management is to restore a normal service as quickly as possible. Usually an incident is resolved by applying a workaround to the system and a new release of software would not be applied at this point since developing a new release would be a much slower activity.

Incidents would normally be channelled through a single system wide Service Desk; however there may be a maintenance organisation (such as the system prime) that has a single point of contact through which to channel incidents. The relevant tracking tools are required in order to track incidents from when they are raised to their closure and agreement of this closure with the originator.

The design phase is carried out using the same tools and processes as were used to build the software in the first place. In maintenance the software will be changed in order to resolve problems, or to implement changes or improvements.

Figure 5-7 : Example ITIL processes

5.9.1.3 Problem Management

A problem is a cause of one or more incidents. The cause is not usually known at the time a problem is created. The problem management process is responsible for further investigation and the recommendation of the fix that will resolve the root cause.

One or more problem fixes may drive the production on a new release of software. How problems are grouped into releases will depend on the priority and severity of the problem.

Decisions not to implement some functions and not to fix some defects in flight software are often made on the basis of whether or not an ‘operational workaround’ exists. This amounts to moving complexity from flight software to mission operations where it is a continuing cost rather than a one-time cost and where it increases the risk of operational error, especially as the numbers of such workarounds accumulate. Operators need to be consulted early and a considered trade-off analysis performed taking into account the costs and risks. Only then should flight software be de-scoped by retaining long term workarounds.

5.9.1.4 Release Management

Release management is the process used in plan releases from determining their content to putting them through transition into operations.

Release management will determine when releases are required in order to meet the customers or system’s needs. It is usual to conduct a review meeting between e.g. the operators of the system, the owner, the maintainer to agree the changes (including problem fixes) that are grouped into releases and when these releases will be rolled out.

The release management process will ensure that the release is on target to meet it roll out date. A test review meeting will be held to make sure that the results of the testing has been agreed and the release is ready to be used. A release Board will then be held. This discusses the suitability of the release and when it can be rolled out onto the system. The Release Board is usually attended by representatives of the operators, maintainers, integrators, safety engineers, trainers. Its purpose is to make sure that all parties have made preparations for the release, the release is ready to be rolled out, and the operators are trained up and ready for its deployment.

5.9.2 Process implementation

-

5.9.3 Operational testing

-

5.9.4 Software operation support

-

5.9.5 User support

-