VERSION COMPATIBILITY MATRIX
Version compatibility matrix format.
The Version Compatibility Matrix (VCM)
(henceforth referred to as "Matrix") shall be maintained
on three levels:-
a. 'Full' CSCI Loads;
b. 'Full' System/Subsystem Loads, i.e.,
Sub-systems, etc.;
c. System Loads.
Where a System load is identified in
terms of its constituent System or segment Loads and each System
or segment shall be identified in terms of its constituent CSCI
Loads.
A VCM shall be prepared showing the
compatible combinations of software (CSCI) versions and hardware
(HWCI) modification states, and shall form a part of the Master
Record Index (MRI). The VCM can also be used to indicate not only
a version but an alternative fit.
The VCM shall comprise:
a. Section 1. A record of:
(1) a list of organisations responsible
for the design of software, including software embedded in PIs;
(2) the corresponding abbreviated codes
for organisations identified at (1);
(3) an explanation of the way in which
control specification drawing numbers can be deduced from the
marking scheme described below.
b. Section 2. A matrix, or matrices,
showing the permissible combinations of hardware and software
for each version of the system.
Development and flight cleared configurations.
The Matrix shall identify both the
software product baseline and the 'flight cleared' configuration,
since prior to a Formal Clearance test and the preparation of
an ARN, a given load will be present in the former but not in
the latter category.
Since a given load cannot be become
'flight cleared' without first being a 'development' load the
above differentiation will be achieved by highlighting the relevant
Matrix entry.
Load identification.
All System and CSCI loads shall be
identified in the form 'Load X/Y', where 'X' and 'Y' are numbers,
'X' (the Release No.) identifies a set of compatible loads and
'Y' (the Option No.) identifies a Load within a set.
For example, Load 2/5 is compatible
with Load 2/3, Load 2/8, Load 2/34, etc., they do not affect the
Load's external interfaces.
From the operator's point of view this
means that all CSCIs with the same 'X' number are, in terms of
software, totally interchangeable.
Impact of changes.
Changes shall be assessed to determine
their effect and hence the level of clearance required:-
CSCI Internal:
Changes which do not affect the CSCI load boundary. These changes shall result in the addition of another Option to the CSCI No.
For example, CSCI'x' V/[n] -> CSCI'x'
V/[n+1].
System Internal:
Changes which are not CSCI Internal but do not affect the System Load boundary. These changes shall result in the Up-issue of the Release Nos of all affected CSCIs and the Option No of the relevant System.
For example, CSCI'x' V/[n] -> CSCI'x'
[v+1]/1, with corresponding changes to CSCI'y', CSCI'z', etc.,
and, SYS'x' V/[n] -> SYS'x' V/[n+1].
External
Changes which affect the System Load boundary. In addition to Up-issuing the Release Nos of the affected CSCI Loads as defined above, these changes shall also up-issue the Release Nos of the affected System Loads.
For example, SYS'x' [v]/[n] -> SYS'x'
[v+1]/1, with corresponding changes to SYS'y' and/or SYS'z'.
Examples.
A typical system load, after the implementation
of a number of changes, may be defined by the following matrix:-
NOTES:
1.
Initially all CSCIs and hence the System
ASM is at No 1/1.
2.
CSCI Internal changes to the System
1 and the System 2 do not affect the System No.
Unique identification.
The Matrix does not define a unique
identification number for each Software Load. To do this, every
possible combination of all compatible Loads would have to be
uniquely identified and this would soon generate an unmanageable
number of combinations or Aircraft Loads.
For example, a system with 15 elements,
each with 3 compatible options, could potentially generate an
unmanageable number of combinations or SW Loads (ASSTs).
The Version Compatibility Matrix identifies
unique sets of compatible Loads from which System and SW Loads
can be generated.
Master record index (MRI).
Except for simple systems for which
the software design records can be treated as though the software
were an additional system module, a subsidiary MRI shall be maintained
for volatile and non-volatile software that is not defined by
the hardware drawings.
Systems with different alternative
software packages may require a separate subsidiary MRI for each
package. The detail layout of the MRI and its issue and control
shall be consistent with the system used for the main equipment.
A simplified depiction of a MRI for a programmable system is shown
in Appendix III figure 1 for guidance including the necessary
information in either an equipment MRI or a software MRI.
Features.
For programmable systems the MRI shall
include the following features:
a. a VCM as described in ;
b. separate records to show the distinction
between:
(1) those software programs or software
changes which have been developed by the Design Authority, or
the Service unit and are fully endorsed and certified by the Design
Authority (Certificate of Design) for normal incorporation in
the design records, and;
(2) those software programs or software
changes which the Service unit has developed and which it is necessary
that the Design Authority is aware of when developing Design Authority
changes. Such software is not embraced by the "Certificate
of Conformance" issued by the Design Authority;
c. a definition of each PI, which
has been developed by the Design Authority, or the Service unit
and is fully endorsed and certified by the Design Authority for
normal incorporation in the design records. When necessary, required
interfaces with Service unit development programs or program segment
shall be defined;
d. the approved version of software
required in the PI at any time of delivery, showing whether the
PI is to be blank, contain dummy software for delivery purposes,
or contain operational software;
e. details of the PIs test equipment
and software loading equipment to be delivered to the Service.
An illustrative example is provided
by Appendix III.
IDENTIFICATION REQUIREMENTS
PIM labels.
The type of label to be applied shall
take into account legibility and the potential need for change.
Programmable item marking (PIM).
The PIM shall be applied as in table
II and shall consist of a label containing the prefix PIM/ followed
by three fields, delimited by dashes, thus:
A code of not more than five characters
signifying the organisation (for example, service unit, contractor)
responsible for the design of the software. Obtain code from document
99-H4-1.
A code of not more than six characters
identifying the control specification drawing number.
A code of not more than two alphanumeric
characters identifying the issue or version of the software specification.
For example:
PIM/K0999-123456-09
| | |
| | |
Field 1 ________| | |
| |
Field 2 _______________| |
|
Field 3 ____________________|
The 13 characters in Fields 1 to 3
inclusive shall be an unambiguous reference to the software control
specification drawing number and issue obtained from the VCM,
thus providing a unique identification of the PI.
A PIM with its corresponding software
control specification is required at the level of software loading
and at each progressive level of assembly (either hardware or
software) until it is accessible at a level from the outside of
the equipment. It is not necessary to apply PIM labels lower than
the point of software loading (i.e., IC PIMs are not required
if the PEC on which they reside is exclusively edge connector
reprogrammable). Table II details the application of PIMs and
an example is given at Appendix I.
Type of lettering.
Letters shall be without serifs (sans-serifs)
such as Gothic or Futura capitals, and numerals shall be Arabic
except when Roman numerals are used for type designation in specifications
and standards. Characters generated by automation techniques (e.g.,
interactive graphics systems or stencils) shall be permitted.
Permanence of labels and markings.
In general, labels of the removable
type should be used. Permanent labels or markings shall be applied
when no reprogramming is envisaged. The label and its method of
attachment shall be such as to avoid the risk of corrosion, due
to the use of unsuitable materials. The label shall remain fixed
to the PI under the environmental conditions stated in the equipment
specification.
Security classification.
To be depicted by normal security classification
colour codes identified in the Documentation Standard, see security
requirements.
Safety critical software.
In the event of safety critical software
being embedded in PI(s), then the item(s) must be clearly identified
with a warning note in supporting documentation.
1. Definition of segment (or LRU) software
control specification.
2. If applicable, definition of system
(or segment) level software loading process.
3. Marking instructions.
By reference to the VCM, the definition
of:
a. the hardware and software installed
in the system (or segment)
b. the software loaded at system (or
segment) level.
Adjacent to the main labelling, datum
plate or exceptionally in the equipment log book or servicing
records.
Mandatory, unless segment (or LRU)
PIMs are readily accessible without major dismantling. Should
be checked automatically during system start-up and displayed
to the user.
1. Definition of module software control
specification.
2. If applicable, definition of module
level software loading process.
3. Marking instructions.
By reference to the VCM, the definition
of:
a. The hardware and software installed
in the LRU;
b. The software loaded at LRU level.
Readily visible on or adjacent to the
LRU labelling.
Mandatory
1. Definition of the component software
control specification.
By reference to the VCM, the definition
of:
a. The hardware and software installed
in the module;
b. The software loaded at module level.
Adjacent to module labelling
Mandatory
1. Not applicable.
2. If applicable, definition of component
level software loading process.
3. Marking instructions.
The software Version of the component.
On component.
Mandatory.
NOTE: This may be applied to packaging.
Adjacent to the NSN of the packaged
item
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk