||Closely coupled software-hardware development
||Skilled & experienced staff
||Evolved over 40 years of space instrument development
||Tuned to size and type of developments.
(Simultaneous software and hardware development, non-contractual
relationships, evolving requirements, small local team)
||Significant commonality with ECSS / ISO9001
||Documented requirements, ICDs, design and test specifications
||Configuration control including NCRs and ECRs
||Coordinated phased development, scheduled & prioritised,
progress monitoring, testing
||Essential for successful development
||MSSL softwares are in full operation in space after our extensive
tests on the ground
The software development environment for space scientific instruments at MSSL
is unlike many 'classical' environments in quite major aspects.
The software developments are not for simple implementation on an already
existing system, or even on a computing system that is yet to be specified
and purchased. The developments are for a scientific instrument which in
itself has to be completely developed over the same time period.
This leads to a software development environment closely coupled to the
corresponding instrument hardware development. Significant difference between
software and hardware development are outlined as follows:
| Software models oriented more to functionality progression
|| Hardware models more oriented to higher quality build
| Intermediate deliveries
|| Not just at major EM/FM phases
| Extensive use of software simulators
|| Hardware not available, or access restricted during development
| Archive all releases
|| Not just EM and FM software deliveries retained
| Backup code
|| Hardware analogy is spare model
| Provide security against code hacking
|| Not a hardware issue
| Post launch development (problem fixing and enhancements possible)
|| Hardware development has to stop at launch
Also, as the requirements are generally not fully known at the outset, a
'classic' approach of complete design, followed by coding, cannot be followed.
An overall flexible design, in which functionality can be implemented as it
becomes known, is required. There is also little room for iteration due to
time and resource constraints. In consequence, MSSL has evolved software
project management & Software Quality Assurance (SQA) processes over many
years which are closely allied to the corresponding hardware development
processes. Also, in addition, they are usually modified to adhere to quality
standards set by the particular space agencies. The software management and
SQA processes as a result have significant commonality with ESA ECSS
and ISO9001 SQA standards. At MSSL it is recognised that Software Quality
Assurance is the responsibility of everyone. It is the responsibility of the
first person who detects a problem to ensure that it is dealt with
appropriately. A brief summary of the resulting processes designed to ensure
quality software, include:
Software Project Management
- Phased development (Design Study, Breadboard, Engineering Model, Flight Model)
- Project Planning (Schedule production, milestones, resources)
- Progress Monitoring (Consortium meetings, project meetings, software meetings)
MSSL Minimal Software Engineering Process document
outlines a minimal process to follow when developing software at
MSSL. It should be followed if no other, higher standards are
Requirements are essential to defining the scope of a job.
- to clarify understanding between the initiator and the programmer
- clarify and agree how much effort and elapsed time are needed for the job (c.f. project schedule)
- what items are to be delivered (what are the outputs)
The minimum requirements
documentation is a numbered list.
Design must be written down before coding starts.
- demonstrates the understanding of the requirements by the programmer
- should include a picture showing how the s/w will work.
- this does not need to be formal,
rather the requirement is
clarity for the initiator's understanding. More important to
show the logic of the s/w than the physical implementation.
- this forces the initiator to think about the completeness of what
they have asked for. Hence will expose gaps in thinking.
- identify required inputs or starting conditions
- allows a break-down of the job into sub-tasks which presents a way
of monitoring progress
- the physical design of code in diagram and words will support
operations and maintenance of the code.
- The Design document must be read and agreed by initiator.
- consistent with documented design
- stick to the scope of requirements but try to be flexible to ease
- plenty of comments to aid maintenance! (but also this is part of
- numerical accuracy
- robustness of code (stress tests)
- against Requirements to demonstrate completeness
+ results required as hard-copy
be agreed by initiator
User guide / OM guide (if required)
- Can re-use parts of design doc to explain functionality and support
- Can re-use test material as a tutorial
For all external deliveries we need a :-
Documentation and s/w release process:
must be approved by project manager
PA Process: Minimum standards must be maintained even by project
If early drafts are to be
released this must be made very clear - and agreed by
(TBD depending on the project)
Software is developed within the above project phases, with each functional element being added generally as a layer across an overall design base. A significant time is required to establish a suitable design base, and the required simulators (in the absence of real hardware) for testing in the early stages of a project. The general philosophy is 'develop a little' and 'test a little' to detect problems early.
- Documented Requirements
- Coding Standard
- Development (Design, coding, debugging)
- Verification (At unit, instrument & spacecraft levels)
Configuration control is to ensure that only authorised changes are made to software, and is usually implemented when the software is submitted for formal integration and testing, prior to a delivery.
The following procedures are then followed for configuration controlled software :-
- NCRs (Formal 'Non-Conformance Reporting' procedures)
- ECRs (Formal 'Engineering Change Request' procedures)
- CIDL (Configuration Item Data List. This is produced to specify
the exact versions of the software for testing and delivery.)
- Archiving (Configuration controlled software is archived for future reference.)
- STD (A 'Software Transfer Document' for the associated software delivery is produced. This specifies the CIDL, current
functionality supported or omitted, and any
outstanding NCR's and ECRs, and complete build instructions for the delivered software.)