- Information
- AI Chat
Introduction about System Engineering
Computer Science and Engineering (CS8493)
Anna University
Recommended for you
Preview text
OME753 /System Engineering Units - I notes
1 Introduction about System Engineering
While elements of systems engineering are recognizable in all major engineering ventures throughout history, the discipline is relatively young. The term was first used in Bell Telephone Laboratories in the 1940s in the context of taking a systems view when engineering networks. Systems engineering provides the framework within which complex systems can be adequately defined, analyzed, specified, designed, manufactured, operated, supported, and ultimately retired.
The focus of systems engineering is on the system as a whole, and the maintenance of a strong interdisciplinary approach. Project management, quality assurance, integrated logistics support, and a wide variety of engineering disciplines are but a few of the many disciplines that are part of a coordinated systems engineering effort.
1 Definition of a System
In systems engineering, defines a system as a combination of interacting elements organized to achieve one or more stated purposes. This definition implies that a system comprises internal system elements with interconnections (interactions) between elements and, by the very act of identifying the system that we are interested in, an external system boundary is implied**.**
As illustrated in Figure 1-1, when we draw the boundary around selected system elements, we define the system of interest (SOI) which consists of those system elements and their interconnections that exist within the defined boundary.
The purpose of the system is called its mission clearly stated by business management and stakeholders 4 which represents the start point of the design process as well as providing the basis for the ultimate test of the system9s fitness-for-purpose once it has been fielded. In the broadest sense, the mission of the system is to provide a solution to a business problem. This narrowing of the general use of the term 8system9 is very important because it has two major implications: *When we refer to a system as comprising system elements that are interconnected in order to achieve the system9s mission, we imply that all three of those principal aspects result from conscious choice. That is, we are referring to systems that have been deliberately designed, or engineered 4 hence our interest in systems engineering. *A system that has been engineered to perform a specified mission must be able to perform that mission with relative autonomy 4 that is, it must be managerially and operationally independent.
1 Types of Systems
There are numerous ways to classify systems 4 here we identify the four main types in order to be clear as to which type of system we refer to in systems engineering.
Closed or open systems
An open system interacts with its operating environment 4 It accepts inputs from that environment across its boundary and returns outputs across the same boundary to the external environment. A closed system is isolated from its external environment and is not useful. We are therefore only interested in open systems.
Natural or human-made/human-modified systems
Natural systems contain natural elements and are the result of natural processes; Human-made systems come into existence through the efforts of humans and may contain human-made elements or natural elements adapted to human-designed purposes (called human-modified systems). The systems engineering for natural systems is certainly not conducted by humans, so we are only interested in humanmade/modified systems.
Physical or conceptual systems.
Physical systems exist in a physical form; Conceptual systems, such as economic, political and religious systems, Do not have a physical form. We focus here on physical systems made up of combinations of integrated hardware and software items.
Precedented or unprecedented systems
In a precedented system, similar such systems have been produced before. An unprecedented system is one that has not been previously produced. Systems that comprise mostly unprecedented elements are the result of research and development effort. Here we focus on systems that comprise largely precedented elements 4 that is, those to which engineering is appropriate.
The majority of the standards discussed refer to open, physical systems that are Human made/modified from largely precedented elements.
1 A System and its Environment In engineering physical systems that are open, our SOI in Figure 1-1 must accommodate external interfaces (inputs/outputs) across the system boundary to external elements that exist in an external operating environment 4 see Figure 1-2.
1 A System as a Capability—A Capability System
we must acknowledge that the systems we are interested in are much more than an aggregation of hardware or software products.
Consequently, a system must be described in terms of all of its constituent elements, including: The major hardware and software products, the organisation within which it will be fielded, the personnel who will interact with it in many ways, the collective training systems required, as well as the facilities, data, and support required to keep the system in service, and the operating procedures and organisational policies. The system is fully defined by the combination of these resources operating in an operational environment in order to achieve some purpose. In that sense then, we could define a system as delivering an operational capability. It is common, therefore, particularly in defence environments, to refer to the system at this level as a capability system.
The capability system is considered to comprise fundamental inputs to capability (FIC): command and management, organization, collective training, major systems, personnel, facilities and training areas, supplies, support, and industry.
Having acknowledged all of the elements of a capability system, it must also be recognized that each of the elements will most probably have a different acquisition cycle 4 for example, people are 8acquired9 in a different manner to that in which the major equipment will be developed 4 and each element of the capability may even be acquired through a different acquisition element in the organisation.
However, that this acquisition is being undertaken in parallel with the acquisitions of the other elements of the desired capability and that all the elements must be brought back together prior to introduction into service in order to field an operational capability.
Example 1: Capability System Elements for our Aircraft Example Resources for our aircraft system example could include, but not be limited to:
Major Equipment. The most tangible part of the system is the hardware itself. The aircraft will be produced, distributed and sold to operators who will then use the aircraft in a number of different ways such as domestic and international operations. Software is also now a critical item within most systems. The aircraft is likely to use hardware and software to control a
range of functions from engine management, through navigation and environmental control systems, to the communications and flight-control systems. Personnel. Air crew are required to operate the system. Ground crew are required to maintain and support the fleet of aircraft. Support. Maintenance facilities and equipment are required for routine maintenance and repairs throughout the aircraft9s life. Materials are required to operate the system, including fuel, lubricants and other consumables such as tyres and spare parts. Facilities. Other facilities such as terminals are also necessary to operate the aircraft and its support systems. Organisation, Policies and Procedures. ACME will need to conform to a significant number of regulations and will need appropriate organisational structures, policies and procedures in order to be able to operate the aircraft effectively. Collective Training. Air crew and ground crew for the system will require training throughout the system life cycle. Data. Data is required to maintain and operate the aircraft. Data could include maintenance information such as specifications and drawings, and operational information such as user manuals and instructions.
1 Logical and Physical Descriptions of a System
A system can be described in two broad ways 4 in logical terms and in physical terms. A logical description of a system articulates what the system will do, how well it will do it, how it will be verified, under what conditions it will perform, and what other systems will be involved with its operation. A physical description relates to the system elements and explains what the elements are, how they look, an how they are to be manufactured, integrated, and verified.
The logical description contains the 8whats9 of the system, and the physical description contains the 8hows9. Both the logical and physical descriptions of a system comprise a series of statements called requirements
The two descriptions are valid independent descriptions of a system, and it is very important that a system is described both logically and physically, focusing first on the logical description:
An initial focus on the logical description therefore allows us to provide novel solutions to new (or even old) problems 4 if we focused on the physical description initially, we would always tend to solve new problems with old physical building blocks.
The logical description or architecture is therefore often called a functional hierarchy, or a functional architecture.
1.1 Physical Hierarchy
In a physical sense, we saw earlier that a system can be considered to comprise operational (end) products and enabling products. The end products of systems are also normally described in a hierarchy 4 here we use a four-layer hierarchy. We describe a top-level entity known as the system that comprises a number of subsystems that comprise a number of assemblies that comprise a number of components. For example, Figure 1-7 illustrates what is perhaps the most complete physical hierarchy of system elements as defined,which also adds entities such as products, subassemblies, subcomponents, and parts to our simple four-layer taxonomy.
Figure 1-7. Hierarchy of elements of a system
For example, at the highest-level of an aircraft, we would consider that the aircraft system contains, among others, the engine subsystem.
The engine subsystem may consist of assemblies such as fuel tanks, pumps and lines, turbines, compressors, gear boxes, and hydraulic pumps. From the viewpoint of an engine manufacturer, however, the engine is commonly considered to be the system, comprising fuel, power plant, and hydraulic subsystems, and so on. An engine is not able to be considered a system 4 it is only useful as an element of a system
Considers an SOI to comprise a combination of interacting system elements, some of which may be systems in their own right 4 as illustrated in Figure 1-8. We will see later that the precise bounding of the SOI is a very important part of the system design.
Figure 1-8. Hierarchy of elements of an SOI
1 Collections of Systems
If a system comprises a set of interacting elements, there are a number of types of ways in which those elements can be collected.
First, we are not always careful to make the distinction between a system and a subsystem. The difference matters because we simply cannot refer to any grouping of elements as a system.
For example, we saw earlier that an aircraft system may contain, among other elements, the engine, which may consist of assemblies such as fuel tanks, pumps and lines, turbines, compressors, gear boxes, and hydraulic pumps.
Commonly, the engine manufacturer will refer to the engine as the engine system. If we continue such a use of the term to the lowest level of components, a nut and bolt can be considered a fastening system because those two elements interact for that purpose. Consequently, if we use the term in that manner, everything is a <system=4which is not very useful.
Figure 1-10. Elements of a subsystem, a system, and a system-of-systems.
There are differences, despite a similar upper-level architecture: SoS. SoS elements are systems in their own right so that they are managerially independent and operationally independent and have been optimized for their own purpose before contributing to the purpose of the SoS. Further, since the constituent systems must be allowed to be optimized for their own purpose, the resultant SoS will invariably be sub-optimal.
System. On the other hand, subsystems are not independent and only exist to serve the parent system 4 subsystems are therefore invariably sub-optimal (from their perspective) since it is the system that is to be optimized, not the constituent subsystems.
Subsystem. Components are not independent and only exist to serve the system as a good servant of the subsystem 4 again, it is the system that is to be optimized, not the constituent subsystems. The attributes of subsystems, systems and SoS are summarized in Figure 1-11.
1 Problem Domain and Solution Domain
A system can be considered to be the solution to a problem. As well as viewing the system descriptions in logical and physical terms, therefore, it is common to consider the activities being undertaken throughout the life of the system to be in either the problem domain (problem space) where we use predominantly logical descriptions, or the solution domain (solution space) where we use predominantly physical descriptions.
Activities in the problem domain (including production of the logical architecture) are generally considered to be the responsibility of the customer (the business owner); activities in the solution domain (including the physical architecture) are generally considered to be the responsibility of the organisation implementing the system (the developer).
1 SYSTEM LIFE CYCLE
A system has a life4at some point in time it doesn9t exist, it is brought into being, it is used, and then it is disposed of once it can no longer serve the purpose for which it was created.
Throughout the life of a system there are a number of phases and activities, each of which builds on the results of the preceding phase or activity.
The sum all these activities is called a system life cycle, which can be described using a model that represents the conceptualization of the business needs for the system, its realization, utilization, evolution, and ultimate disposal.
As shown in Figure 1-12, a generic system life cycle can be divided into four very broad phases:
Pre-acquisition Phase.
The life cycle begins in the Pre-acquisition Phase with an idea for a system being generated as a result of business planning. Early consideration of the possible options results in the confirmation of the early business needs for the system, which are elaborated by a business case that justifies expenditure of organizational resources on acquisition of the system. In some instances, the Pre-acquisition Phase may determine that it may not be feasible or cost-effective to proceed to acquisition (due to technology limitations or funding shortfalls, for example). In that sense then, the Pre-acquisition Phase is where organisations expend research and development funds to ensure that only feasible, costeffective projects are taken forward to acquisition.
If the development of the system is undertaken in-house, the acquisition element of the - -organisation (the acquirer) will engage with the development element (the developer) to develop the system.
It is increasingly common these days for the supply or development to be undertaken by an outside organisation called a contractor, which is the entity responsible for supplying (perhaps by designing and developing) the system to meet the customer requirements.
The relationship between the customer and the contractor varies with each project but, for each project, is defined by the terms and conditions of the contract between the two parties.
In many cases the contractor is not able to perform all of the work required and devolves packages of work to a number of subcontractors. The terms and conditions relating to this work are described in the relevant subcontract.
Responsibility for the various phases of the system life cycle is spread across the enterprise (or organisation) within which the eventual system will operate. Figure 1-13 shows that the initial Pre-acquisition Phase is the responsibility of enterprise management, who conduct business planning and establish the business case for the projects required to support an organisation.
A project is then established with a project charter providing authority to a project manager to expend organizational resources on the acquisition of the system. Systems engineering is an important discipline which is responsible to the project manager to perform the technical management of the project throughout acquisition and utilization.
Once acquisition is complete, and the system is in-service, it is operated by the users and supported by the support element. Note that all parties are involved at all stages in the life cycle, with the roles and responsibilities of each party shifting in emphasis between stages.
1 ACQUISITION AND UTILIZATION PHASES
Systems engineering is predominantly related to the Acquisition Phase and, to a lesser extent, the Utilization Phase of the system life cycle. In the Acquisition Phase, the activities are Conceptual Design, Preliminary Design, Detailed Design and Development, and Construction and/or Production.
In the Utilization Phase, the activities are Operational Use and System Support, which are undertaken in parallel. While there is no standard taxonomy, we choose these activities as a framework here because they are generally accepted in the systems engineering community over the past decade or so, and for the following reasons:
These activities emphasize that a system begins with the perceived business needs and finishes with retirement and, ultimately, disposal of the system 4 the so-called cradle-to- grave approach.
There is a clear delineation between the Acquisition and Utilization (in-service) Phases of a system, which recognizes that there is a period of transition required as the system is transferred from the acquirers to the operators/users.
The activities show sufficient detail in the early stages of the Acquisition Phase (particularly in Conceptual Design and Preliminary Design) where the application of systems engineering methodologies and practices have the potential to make the most significant contribution.
Importantly, within the Acquisition Phase, the activities also differentiate clearly between the problem domain which contains the logical description of the system (the product of Conceptual Design) and the solution domain which contains the physical description of the system (the products of Preliminary Design and Detailed Design and Development).
Additionally, the separation of the early system design into Conceptual (what and why) and Preliminary (how) Design is very important since the responsibility in most programs transitions from the customer for Conceptual Design to the contractor for Preliminary Design.
Figure 1-14. Activities in the Acquisition and Utilization Phases of the system life cycle
The significance of focusing on the system life cycle is that decisions made early in Conceptual Design are informed by the activities proposed to be conducted later in the Acquisition Phase and in the Utilization Phase. For example, the design of an aircraft airframe must take into account the maintenance and operation of that airframe during the Utilization Phase 4 it would be pointless to design the best airframe in the world if it did not have the necessary access points to allow maintenance personnel to service it, nor operators to operate it in the intended environment.
Conceptual Design ends with the System Design Review (SDR), which finalizes the initial FBL. The SDR provides a formalized check of the logical design; communicates that design to the major stakeholders; confirms external interface and interoperability issues; confirms the BNR, SNR and the SyRS; and provides a formal record of design decisions and design acceptance.
1.3 Preliminary Design
The aim of Preliminary Design is to convert the FBL into an upper-level physical definition of the system configuration or architecture.
Preliminary Design is therefore the stage where logical design is translated into physical design; where focus shifts from the problem domain into the solution domain.
The result of Preliminary Design is a subsystem-level design known as the Allocated Baseline (ABL) in which the logical groupings defined in the FBL have been defined in more detail, and then re-grouped and allocated to subsystem-level physical groupings (called configuration items (CI)), which combine to form the upper-level physical design of the system. At the centre of the ABL are a series of Development Specifications, which contain the subsystem-level requirements grouped by CI.
The ABL is so-called because the requirements that are logically grouped in the FBL are 8allocated9 at this next baseline into physical groupings.
The ABL therefore represents a subsystem-level architecture (couched in physical terms) that meets the requirements of the system-level architecture (couched in logical terms) contained in the FBL. The ABL is formalized at the Preliminary Design Review (PDR).
The PDR ensures the adequacy of the Preliminary Design effort prior to focusing on detailed design. PDR is designed to assess the technical adequacy of the proposed solution in terms of technical risk and the likely satisfaction of the FBL. PDR also investigates the identification of CI interfaces and the compatibility of each of the CIs.
1.3 Detailed Design and Development
The ABL developed during Preliminary Design is used in the Detailed Design and Development process to complete development of the individual subsystems, assemblies, and components in the system. Prototyping may occur and the system design is confirmed by test and evaluation.
The result of the Detailed Design and Development process is the initial establishment of the Product Baseline (PBL) as the system is now defined by the numerous products (subsystems, assemblies, and components) making up the total system (as well as the requisite materials and processes for manufacturing and construction).
The definition of the system at this stage should be sufficiently detailed to support the commencement of the Construction and/or Production activities.
The PBL is established at the Critical Design Review (CDR).
*The CDR is the final design review resulting in the official acceptance of the design and the subsequent commencement of Construction and/or Production activities; *CDR evaluates the detailed design; determines readiness for production/construction; and *Ensures design compatibility, including a detailed understanding of all external and internal interfaces.
1.3 Construction and/or Production
The final activity within the Acquisition Phase is Construction and/or Production.
System components are produced in accordance with detailed design specifications in the PBL and the system is ultimately constructed in its final form.
Formal test and evaluation activities (acceptance tests) will be conducted to ensure that the final system configuration meets the requirements in the SyRS.
Construction and/or Production, and the Acquisition Phase, ends with the Formal Qualification Review (FQR), which provides the basis upon which the customer accepts the system from the contractor. The FQR is informed by the results of acceptance test and evaluation (AT&E).
1 Utilization Phase
On acceptance from the supplier, the system moves into the Utilization Phase. The major activities during this phase are Operational Use and System Support. Systems engineering activities will invariably continue during the Utilization Phase to support any modification activity that may be required.
Modifications may be necessary to rectify performance shortfalls, to meet changing operational requirements or external environments to enable ongoing support for the system to be maintained, or to enhance current performance or reliability.
1 Retirement Phase
The system life cycle ends with retirement of the system in the Retirement Phase, which may well overlap with the introduction into service of the replacement system. Functions associated with phase-out and disposal include transportation and handling, decomposition, and processing of the retiring system.
A Retirement Concept should be developed during the early stages of the Acquisition Phase. If considered early, disposal and phase-out issues will form some of the criteria against which the system is designed (8design for disposability9).
It is important, however, that system designers focus on retirement, rather than the more limiting issues of disposal 4 planning for disposal is important, but a system may retire from a number of life cycles before it is ultimately disposed of at the end of life.
Importantly, therefore, the second principal facet of systems engineering is to provide a process by which the components, assemblies, and subsystems can be integrated to achieve the desired system purpose.
The terms system, subsystem, assemblies, and component are relative. Each system comprises subsystems that consist of assemblies that consist of components. Each subsystem, however, can be considered in some areas to be a system in its own right, which has subsystems, assemblies, and components, and so on.
Figure 1-16. Building block concept for top-down development
The system is implemented using a bottom-up approach 4 as illustrated in Figure 1-17 for a simple four-tier system.
1 Requirements Engineering
The life cycle of a system begins with business needs, which are ultimately translated into a large number of statements of requirement that form the basis for the logical design and subsequently elaborated further to form the physical architecture. These transitions must be managed by a rigorous process, called requirements engineering, which is aimed at ensuring that all relevant requirements are included (and all irrelevant requirements excluded).
The establishment of correct requirements is fundamental to the success of the subsequent design activities. Poor requirements cannot be rectified by good design, so it invariably follows that rigorous development of requirements is essential for the acquisition to be successful.
Once requirements have been collected, the systems engineering process then focuses on the derivation and decomposition of these requirements from the system level right down to the lowest constituent component (sometimes referred to as requirements flowdown).
This process involves elicitation, analysis, definition, validation, and management of requirements. Requirements engineering ensures that a rigorous approach is taken to the collection of a complete set of unambiguous requirements from the stakeholders.
Requirements traceability is also an essential element of effective management of complex projects. Through traceability, design decisions can be traced from any given system-level requirement down to a detailed design decision (called forward traceability).
Similarly, any individual design decision must be able to be justified by being associated with at least one higher-level requirement (called backward traceability). This traceability is important since the customer must be assured that all requirements can be traced forward and can be accounted for in the design at any stage.
Further, any aspect of the design that cannot be traced back to a higher-level requirement is likely to represent unnecessary work for which the customer is most probably paying a premium.
Traceability also supports the configuration control (change management) process, especially the investigation of the impact of the change. Support for requirements traceability is a feature of the top-down approach that provides a mechanism by which it can be guaranteed that requirements can be satisfied at any stage. A bottom-up approach cannot provide the same guarantee.
1 Focus on Life Cycle
Systems engineering is focused on the entire system life cycle and takes this life cycle into consideration during decision-making processes. In the past it has been too common to consider design options only in the light of the issues associated with the Acquisition Phase and to pay little attention to through-life support aspects. It is proper for project managers and their teams to focus on the Acquisition Phase of the project and on the development of a system that meets the stakeholder requirements while minimizing cost and schedule.
However, a lack of consideration of whole-of-life considerations can often lead to larger- than-expected costs in the Utilization Phase to be met from budgets that are insufficient to keep systems in service.
Introduction about System Engineering
Course: Computer Science and Engineering (CS8493)
University: Anna University
- Discover more from:
