Close
Software Development at MSSL is based upon:
Coupled Development
Closely coupled software-hardware development
- Documented requirements, ICDs, design and test specifications
- Configuration control including NCRs and ECRs
- Coordinated phased development, scheduled & prioritised, progress monitoring, testing
Comprehensive Testing
MSSL softwares are in full operation in space after our extensive tests on the ground
Standards
- 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
Skilled and Experienced Staff
Essential for successful development
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 | Differences w.r.t. Hardware |
| 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 |
When 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)
Software Development
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
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.)