BS EN IEC 62853 pdf free download

BS EN IEC 62853-2018 pdf free download.Open systems dependability.
4.1 Open systems
Open systems have the following characteristics (111.
— They are large, complex and interconnected.
— They can include black box components.
NOTE 1 A black box component is a component whose users do not know its implementation details and cannot control its functionality and interface.
— Their purpose, objectives, environment and actual performance are not determined and change through their lives. Unpredictable changes of user requirements, service objectives, services received via network, black box components, technological basis, etc., are commonplace.
— Their boundaries, functions and structure are ever-evolving and perceived differently by different stakeholders. Preventing them from becoming vague requires particular effort.
— Accountability is vita’ in their system life cycle and for risk control, but it needs particular effort to establish because of lack of effective central control.
— Understanding of the systems and their risks by their stakeholders is neither complete nor certain at any given time.
— The possibility of failures due to an incomplete understanding of the systems, unanticipated events and changes cannot be eliminated or predicted. Systems need to be resilient, need to have risk controls including error proofing, need to be able to recover from failures and need to be able to adapt to prevent recurrence.
— Achievement of dependability requires an iterative approach and depends on integration of the system operation and development. Performing dependability activities throughout the system life cycle and iterating them as often as needed is particularly important for open systems.
NOTE 2 Some of these features are shared with so-called system of systems [12], (13J and unbounded or weakly bounded systems.
NOTE 3 Depending on a particular point of view. most systems have these features to some. possibly negligible. degree. A system is an open system when these features of the system are significant for the discussion at hand regardless of its being a system of systems.
A system necessarily exchanges services with a wide variety of other interconnected, independently managed systems. These surrounding systems are managed according to their own principles and stakeholders, and their interfaces are subject to change for various reasons. The system must serve diverse stakeholders. Each stakeholder has different objectives and there might be no single authority over the system: moreover, the objectives of the system and the surrounding systems change with time. The conditions for the system, such as requirements and constraints, change frequently and unpredictably. Thus, there are uncertainty and incompleteness about these conditions and they cannot be understood completely at any given time.
Since an open system changes continuously through its life, the design process, as modelled by the spiral product development model, will to some extent continue during the whole lifetime of the system.
Moreover, uncertainty and incompleteness are also present within the system itself, such as with respect to its functions, internal structure, and the boundary. Its subsystems are often managed by different parties and those involved in integration and coordination of the system boundaries might not have complete knowledge and control of them. Services and components might be added to or removed from the system during its operation by/for various stakeholders. This dynamic nature makes the system boundary, functions and structure ambiguous in practice, even if there is no ambiguity in theory at any specific time from a specific point of view.
BS EN IEC 62853:2018
— 12— IEC 62853:2018©IEC 2018
For these reasons, as well as the sheer complexity and scale of the system, it is very difficult for any stakeholder to specify, comprehend or control the system and its management to any sufficient completeness and certainty. Unanticipated changes and failures of various degrees are a part of the system’s nature. The use of the term open systems emphasises this aspect of systems.
The true, implicit expectations for the system are always relative to the context of other surrounding systems and stakeholders. The objectives of the various levels of systems surrounding the target system should be taken into account. As the context changes, and as incompleteness and uncertainty are resolved in one way or the other, the system should adapt to the corresponding changes in the requirements and assumptions. These changes cannot be fully anticipated or specified in advance.
4.2 Dependability issues specific to open systems
Open systems dependability aims to achieve service continuity over extended periods of time notwithstanding changes and failures. Achieving service continuity places requirements on the entire life cycle of the system and iteration thereof aided by enhancement activities.
Dependability management provided by IEC 60300-1 generally applies to open systems and this document shall be used together with IEC 60300-1. IEC 60300-1 requires that sustained improvement be ensured via planning and control of enhancement activities and appropriate reviews of progress. Open systems dependability elaborates on this for open systems where dependability directly depends on improvement with respect to frequent unpredictable changes. An iterative approach to the life cycle can be applied to accommodate such changes; see Annex A.
The scope of dependability management of an open system is not trivial because of characteristics explained in 4.1. Merely conforming to explicit agreements is not sufficient because agreements cannot adequately cover all aspects of the system of interest, as no open systems can be completely defined. Stakeholders need to be prepared to act beyond the agreements based on a common understanding of the system and its environment. As a principle, open systems dependability strives for confidence and trust in the system even under broken assumptions, requirements invalidated by changes, and eventual system failures.
The argument above highlights the importance of processes that continually review and revise the scope of dependability management and that provide explicit documentation and an agreement on the scope. The agreement on the scope by stakeholders needs to be backed by agreements on accountability.
Unanticipated causes cannot be prevented. What can be done is to identify key functions, anticipate possible consequences of losing the key functions and protect the key functions so that they can be recovered quickly or covered by redundancy.BS EN IEC 62853 pdf download.