Appendix E to SW 01 - Architectural Considerations
1 Introduction
1.1 This Appendix discusses various aspects of software architecture that can influence software safety assurance by having an impact on the structure and content of the software safety argument and its supporting evidence.
2 Architectural Units
2.1 The notion of architecture is often limited to a physical architecture of equipments linked by physical connections. Thus interference is only precluded due to the physical properties of the equipments or interconnections. Such views of architecture originally arose from mechanical and analogue views of the world, where data is represented by a physical property e.g. the length of extension of a rod or the voltage existing on a wire.
2.2 The concept of logical properties, e.g. data value, timeliness, etc., do not exist in this view of the world and so protecting the entities described by such properties from interference cannot be discussed. Consequently, the view adopted makes it difficult to deal with software, as it implies that since all the programmes running on a single computer are part of the same equipment, architecture cannot be used to preclude interference between the programmes.
2.3 This Appendix uses a broader notion of architecture by introducing the concept of logical architecture, where reliance may be placed on physical properties of the system to preclude interference with logical properties. The logical properties of particular interest to a computer programme are those of data, timeliness, order and access to a resource. For example, data is represented in a computer by its value (a number) and its location (in memory). Clearly, it shares its location with other programmes so cannot be physically isolated. Thus it may be interfered with. However, by managing a programme's access to memory, it may be possible to be assured that access to the data of one programme cannot be granted to another.
2.4 There are (at least) two simple ways of limiting access to data:
.
Make sure a programme runs to completion and does not use data in RAM from one run to the next.
.
Set bounds on the memory access for each programme and make sure they do not overlap.
The first requires a simple non-interruptible scheduler to handle multiple programmes whereas the second usually requires some hardware and software to enforce separation; in both cases the implementation is physical while the policy itself is logical. However in the first case the implementation is via some software, which some may not consider to be 'architectural', whereas in the second case hardware is used, which is always considered 'architectural' - this apparent mix of physical and logical architecture often causes confusion.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：CAP 670 Air Traffic Services Safety Requirements 1(90)
