Common errors architecture

Material limitations not commonly known to the architectural practitioner, which will affect design are listed. Lack of knowledge of corrosion resistant masonry construction has resulted in costly mistakes. This approach will appear sophomoric but such errors have occurred with sufficient frequency to warrant inclusion. The information is covered more specifically and in greater detail in other chapters. While redundant, it is important that the less experienced be forewarned of these limitations. 

Some passive controls will live outside the user interface and may not be apparent to day-to-day operators. For example, HIT systems typically need to exhibit resiliency in their architecture whether brought about through redundancy or other systematic means. These design features represent active engineered controls. However it is common for this to be supported by other more passive controls which require some degree of human intervention. The platforms on which systems reside can often be monitored for availability and performance. In some cases systems may be specifically instrumented to provide metrics on the execution of specific functions or the success of database transactions. Similarly systems may log errors or failed messages which are then made available for inspection by service management personnel. 

Software faults may be SCCFs when the same software is used in identical redundant units in a system architecture as it is the case in the Tihange 1 NIS and when they are triggered by a condition common to all channels. For instance, a neutron flux going over a threshold limit. As we know that software faults can only be design faults, the best way - and may be the only way- to prevent software SCCF is to make sure that SCCF prone software components are as error free as possible . 

The proposed functional architecture has no common mode vulnerabilities. As can be seen in Table 3.1, independence attributes are key to protect against common mode errors. There are two factors to consider here ... 

A preliminary system safety assessment (PSSA) is essential in order to determine (and agree) the depth of assessment needed, the criteria utilised and the manner in which the safety objectives are to be accomplished. The PSSA concentrates on the functions and vulnerabiUties of the system instead of the detailed analysis, and can thus be conducted prior to the definition of the system s architecture. The PSSA remains a live document until the final SSA can be issued. By the preliminary design review (PDR), the PSSA should include functional failure consequences to the aircraft and its occupants consequences of other possible malfunctions of a system (e.g. overheating) and their effects on surrounding systems consequences to the system of failure in other systems or parts of the aircraft, identification of any possible common-mode failures or cascade failures which my need detailed investigation the identification of possible vulnerabilities to flight crew or maintenance error. 

---