Applied Systems Engineering (this chapter is from my book Engineering Excellence DNA) – Georgios Ardavanis Ph.D.

Delivering The Highest Quality Fabrics

Systems engineering refers to the building of engineering concepts. The need for systems engineering arose with the increasing complexity of systems and projects, in turn exponentially increasing the likelihood of component friction, and hence design unreliability. When we speak in this context, complexity includes not only engineering systems, but also logical human data organization. At the same time, a system can become more complex due to the increase in size as well as the increase in data volume, variables or the number of fields involved in the design.

Systems engineering is an interdisciplinary field and tool that allows the development and management of complex systems in different disciplines which are designed, integrated, validated, deployed, maintained, and operated over their life cycle. Systems engineering utilizes a holistic way to investigate factors and interactions that could contribute to a possible outcome – called Systems Thinking Principles158 (system approach, holism, synthesis, and organicism) – in order to organize this body of knowledge and deal with work-processes, optimization methods, and risk management tools in such projects. Its concept covers all technical and anthropocentric disciplines. Systems engineering ensures that all possible aspects of a project or system are taken into account and integrated into a set. The systems engineering process begins with discovering the real problems that need to be solved and identifying the most likely or significant failures that may occur – systems engineering involves finding solutions to these problems.

Traditional systems engineering was considered a branch of engineering in the classical sense, that is, it was applied only to physical systems, such as spacecraft and aircraft. More recently, systems engineering has evolved into a broader concept, especially when humans were seen as an essential component of a system. In line with the broader field of systems engineering, the Systems Engineering Body of knowledge (SEBoK)159 has defined three types of systems engineering: (1) Product Systems Engineering is the traditional systems engineering that focuses on the design of physical systems consisting of hardware and software; (2) Enterprise Systems Engineering refers to the view of companies, that is, organizations or combinations of organizations, as systems; (3) Service Systems Engineering has to do with service systems engineering (according to Peter Checkland160 a service system is a system which is conceived as serving another system).

David W. Oliver161 argues that the systems engineering process can be decomposed into: (1) Systems Engineering Technical Process. (2) Systems Management Process. In Oliver’s model, the goal of the Management Process is to organize the technical effort in the life cycle, while the Technical Process includes the evaluation of the available information, the definition of effectiveness measures, the creation of a behavior model, the creation of a structure model, the exchange analysis, and create a sequential construction and test plan.

The holistic integrative discipline combines contributions and balances trade-offs among cost, schedule, and performance while maintaining an acceptable level of risk covering the entire life cycle of the item.

Figure 24 illustrates the range of systems engineering activities. The systems engineering program will outline the requirements to be followed by the systems contractor during the development and implementation of its processes. Systems engineering is the process of systematically combining system components according to design requirements to ensure that all the sub-systems operate and act as a complete, secure, and reliable system.

An important part of this overall work is identifying and documenting key system interfaces between different sub-systems. These can be physical, logical, and organizational interfaces. To achieve a successful system integration program, the design and build contractor(s) must develop various designs at the initial stage of the design life cycle. Systems engineering is the most suitable for multidimensional and multifaceted projects. That is, these projects usually involve people from many industries and sectors working together for a long time. Systems engineers need certain tools to deal with the complexity of the project. That is, goal setting, facilitation of interface communications, and process management.

Systems engineering projects require the involvement of the right engineers who are fully informed in agreed decision-making points, so that the project life cycle supports better decision-making and future planning through clarity of responsibility, mutual understanding, and common language. Clarity and accountability usually require the provision of a responsibility assignment matrix or a linear responsibility table and is applied at the beginning of the projects. This is a simple technique and provides clarity of roles and responsibilities, helping to avoid confusion between the various sub-systems involved and stakeholders. In terms of mutual understanding, engineering experts share the same goal, although project management and systems engineering will of course have different concentrations in skills, competencies, perspectives, and culture.

Understanding each other is a required navigation lesson to improve project results. The agreement and use of a common language require the implementation of a common glossary. A common glossary can further help the common language, while at the same time it will reduce any misunderstandings and confusion between different sub-systems. Systems engineering usually faces many challenges because it has to integrate many assets, disciplines, and geographical boundaries, along with sub-systems and procurement packages at the same time. For example, the design and construction of a new electric railway is a complex multidisciplinary task, requiring close interaction and coordination between the various parts, sub-systems, and the entire operating system. Any interfaces that have been previously identified and tested must be integrated and tests and commissioning must be performed. Also, it must be considered by the systems engineer that the integration of the systems takes place in the context of procurement for inter-contractual interfaces as well as between procurement contracts for inter-contract interfaces during the preliminary and final design respectively. Systems design is simply the design of systems and requires a systematic and rigorous approach to design. This approach is usually required by the scale and complexity of many sub-systems. While performing systems engineering it is very important to ask the following questions:

1. What system should be applied to the project?

2. What will be the environment of the proposed system?

3. What is the purpose of the system in relation to its direct and indirect operating environment?

4. What is the feedback loop with which the system corrects its actions?

5. How does the system measure if it has achieved its goal?

6. Who defines the system, the environment, and the goal? And who is monitoring it?

7. What resources does a system have to maintain the relationship it desires?

8. Are his resources sufficient to achieve his goal?

 

Thus, the scope of systems engineering is the process of deliberately assembling parts of the system into an operating whole system, such as the physical assembly of components; the connection of different conduits, cables, and hoses; the connection of electronics to power sources and electronic systems; the uploading of systems control, test, and system software; and

condition for system control. The sequence with which system engineering occurs is of great importance and criticality. In complex systems many errors are discovered only during system integration and testing. Systems engineering should be undertaken at the beginning of the design and build phase of a project and focus on analyzing and exploiting customer needs and required functionality early in the development cycle, documenting requirements, and then continuing design synthesis and system validation, taking into account the complete problem, the system life cycle. This includes a full understanding of all the stakeholders involved. David Oliver claims that the systems engineering process can be decomposed into a technical and management process respectively. In Oliver’s model, the goal of the management process is to organize the technical effort in the lifecycle, while the technical process includes evaluating the available information, defining effectiveness measures, creating a behavioral model, creating a structure model, performing trade-off analysis, and the creation of a successive construction and test plan. Depending on their application, although there are many models used in the industry, all of them aim at identifying the relationship between the various stages mentioned above and incorporating feedback. Examples of such models include the Waterfall model162 and the Vee model163.

 

System development often requires input from different technical disciplines. Providing a holistic picture of the development effort, systems engineering helps all technical contributors to become a single team effort, forming a structured development process that goes from concept to production to operation and, in some cases, to termination and disposal. In an acquisition, holistic consolidation discipline combines contributions and balances trade-offs among cost, schedule and performance while maintaining an acceptable level of risk that covers the entire lifecycle of the item. Regarding the systems engineering process, depending on their application, different tools are used for different stages of the systems engineering process, such as: (1) Introduction of the process; (2) Requirements’ analysis; (3) Functional analysis/allocation; (4) Systems analysis and control; (5) Synthesis; (6) Output process. Figure 25 illustrates the complete approach to the systems engineering process, where the fundamental process is divided into three phases: (1) Input process; (2) System analysis and control; and (3) Output process. 

Systems analysis and control require a thorough investigation of the requirements’ analysis, functional analysis/allocation, and system synthesis. The synthesis of the system is done through many tools, such as: (1) Trade-off studies164; (2) Effectiveness analyses; (3) Risk management; (4) Configuration management; (5) Interface management; (6) Data management; and (7) Performance management. Between the phases of functional analysis/allocation and requirements analysis there is a continuous cycle of requirements for the validation of contractual requirements. There is a continuous design loop between the synthesis and functional analysis/allocation phases which further validates the application of the requirements. There is also a verification loop that verifies for final approval all the requirement entries of the contract.

Models play important and different roles in systems engineering. A model can be defined in a number of ways, including an abstraction of reality designed to answer specific questions about the real world, or representation of a real process, or structure; or a conceptual, mathematical, or physical tool to assist a decision maker. Together, these definitions are broad enough to include physical engineering models used to verify a system design, as well as schematic models such as a functional flowcharts and mathematical models used in the design process.

The main reason for using mathematical models and diagrams in engineering studies is to provide estimates of systems effectiveness, performance or technical characteristics and cost from a set of known or estimated quantities. Usually, a collection of separate models is required to provide all of these variable results. The heart of any mathematical model is a set of significant quantitative relationships between its inputs and outputs. These relationships can be as simple as adding component quantities to obtain a set, or as complex as a set of differential equations describing a complete system. Ideally, these relationships express causality, not just correlation. Another key to successful systems engineering activities is also the methods with which these models are efficiently and effectively managed and used to simulate systems.

However, a variety of fields often present recurring modeling and simulation problems, and new developments aim to intersect methods between distinct scientific and engineering communities, under the heading of modeling and simulation systems.

When it comes to modeling standard and graphical representations, the primary purpose of a systems engineer is to understand a complex problem, graphical representations of a system used to communicate the operating specifications and data of a system. Common graphs include the Functional Flow Block Diagram (FFBD)165; Model Based Design166; Data Flow Diagram (DFD)167; N2 Charts168; IDEF0 Diagram169; Sequence Diagram170; Block Diagram171; Signal Flow Graph172; USL Function Maps and Type Maps173; Enterprise Architecture Frameworks174; and Model-Based Systems Engineering.

A graph relates to the various sub-systems or parts of a system through functions, data, or interfaces. Any or all of the above methods are used in an industry based on its requirements. For example, diagram N2 chart can be used where interfaces between systems are important. Part of the design phase is the creation of structural and behavioral models of the system. Once the requirements are understood, it is now the responsibility of the systems engineer to improve them and determine, along with other engineers, the best technology for the job. At this point starting with a trade-off study, systems engineering encourages the use of weighted choices to determine the best option. A Decision Matrix, or Pugh Matrix175, is one way (Quality Function Deployment (QFD) is another) to make this choice, taking into account all the important criteria. The trade-off study in turn updates the design, which again affects the graphical representations of the system (without changing the requirements). In the systems engineering process, this step represents the iterative step that takes place until a feasible solution is found. A decision matrix is often completed using techniques such as statistical analysis, reliability analysis, systems dynamics (feedback control), and optimization methods. Overall, there are many areas and fields that can be considered closely related to systems engineering. These areas contributed to the development of systems engineering as a separate entity.

Cognitive systems engineering is a specific approach to the description and analysis of human machine systems or socio-technical systems. The three main themes of “cognitive systems engineering” are how people deal with complexity, how work is accomplished using artifacts, and how Human Machine Systems176 and Socio-Technical Systems177 can be described as a joint cognitive system. Cognitive systems engineering has since its inception become a recognized scientific discipline, sometimes referred to as Cognitive Engineering178. The concept of a “joint cognitive system” has been widely used as a way of understanding how complex socio-technical systems can be described with varying degrees of analysis.

Systems configuration management or configuration management as applied in the defense and aerospace industries is a broad-systems level practice. This area is parallel to the tasks of systems engineering, where systems engineering deals with the development of requirements, the allocation of development elements and the verification. Configuration management deals with requirements capture, traceability of the development item, and audit of development item in order to ensure that it has achieved the desired functionality that system engineering and test and verification engineering have proven out through objective testing.

Interface design and its specifications are about ensuring that the components of a system connect and operate with other system sub-systems and external systems as required. Interface design also includes the assurance that system interfaces are capable of accepting new features, including mechanical, electrical, and software interfaces, including reserved wires, plug-space, command codes, and bits in communication protocols. This is known as extensibility. Human-Computer Interaction or Human-Machine Interface (HMI)179 is another aspect of interface design and is a critical aspect of modern systems engineering. The principles of systems engineering apply in the design of network protocols for Local Area Networks (LANs) and Wide Area Networks (WANs).

Performance engineering is the discipline of ensuring that a system meets customers’ expectations for lifetime performance. Performance is usually defined as the speed at which a particular function is performed or the ability to perform several such functions in a unit of time. Performance can be degraded when a queue of functions to perform is throttled by limited system capacity. For example, the performance of a packet switching network is characterized by the end-to-end of packet transit delay or by the number of packets that change in one hour. High-performance systems design uses analytical or simulation modeling, while the delivery of high-performance implementation involves thorough performance testing. Performance systems engineering relies heavily on statistics, queueing theory, and probability theory for its tools and processes. Program management and project management have many similarities with systems engineering, but they have a broader origin than engineering. Project management is also closely related to both program management and systems engineering. Proposal engineering is the application of scientific and mathematical principles to the design, construction, and operation of a cost-effective proposal development system. Basically, proposal engineering uses the system engineering process to create a cost-effective proposal and increase the chances of a successful proposal. Reliability systems engineering is the discipline of ensuring that a system meets customers’ expectations for reliability throughout its life, (i.e., it does not fail more often than expected). Next to failure prediction is the same as failure prevention. Reliability engineering applies to all aspects of the system. It is closely linked to maintenance, availability, and logistics engineering. Reliability systems engineering is always a critical component of safety engineering, such as in Failure Modes and Effects Analysis (FMEA) and hazard fault tree analysis, and safety engineering. Risk management is one of the interdisciplinary parts of systems engineering. In development the inclusion of risk in exchange with costs, schedule, and performance characteristics involves the iterative complex configuration management of traceability and evaluation of programming and requirements across all sectors and for the system lifecycle that requires an interdisciplinary technical approach to systems engineering. Systems engineering has risk management to define, adapt, implement, and monitor a structured risk management process that is integrated into the overall effort. One of the main tasks of systems engineering is to clarify and define the project roadmap in accordance with:

§  Coordination of the overall project technical activities.

§  Supply of technical assistance to the contractor’s project and technical management.

§  Insurance of the application of quality processes on technical activities.

§  Meeting of the cost and delivery targets, the utilization of previous experience on similar projects, the definition of the system through the development of requirements.

§  Functional requirements and operational system specifications, and the system architecture definition.

§  Specification of the sub-systems scope of works in terms of function.

§  Operation and performance.

§  Insurance of identification, resolution, and implementation of functional and technical interfaces (internal and external).

§  Integration of the sub-systems into the whole system.

§  Integration of the system with the local environment.

§  Testing and commissioning of the complete system.

§  Qualification and insurance of the system performances.

§  Carrying out of the system’s technical risks assessment and mitigation.

§  Insurance that the contract requirements are fulfilled at each step of the systems’ development and throughout the complete project cycle life (requirements traceability).

§  Insurance of the systems consistency through functional and technical interface management.

§  Validation of the rail systems during the test running.

§  Assistance of the O&M (Operation and Maintenance) group during the trial operation.

 

The system specifications are defined as the first stage of the system processing and in addition it is divided into three major phases. In the first phase, the development of system requirements will define the basic requirements base, which will then be the basis for the development of the whole system. These requirements will cover functional, architectural, safety, RAMS and other aspects of system design and construction. In the second phase, the system definition will define the functional requirements, operating specifications, and system architecture to meet the contractual requirements. Functional requirements and operational specifications are considered together to ensure consistency of system specifications. In the third phase, the system interface specifications will determine how the environment will interact with the whole system and how the sub-systems will interact within the system, so that, in the integration phase, they will integrate smoothly with each other.

The system specifications are based on the combination of two concurrent processes: Top-down and bottom-up respectively. A top-down approach is essentially breaking down a system to get an idea of its synthetic sub-systems by reverse engineering. A top-down approach provides an overview of the system, which identifies, but does not describe in detail, each first-level sub-system. Each sub-system is then refined in even greater detail, sometimes at many additional sub-system levels, until the entire specification is reduced to key components. A top-down model is often determined with the help of black boxes, which makes it easier to handle. However, the black boxes may not clarify the basic mechanisms or may be detailed enough to validate the model realistically. The top-down approach starts with the big picture and splits from there into smaller sections.

A bottom-up approach is the synthesis of systems to create more complex systems, thus making the original system sub-systems into the emerging system. Bottom-up processing is a type of information processing that relies on incoming data from the environment to form a perception. From the point of view of cognitive psychology, information enters the eyes in one direction (sensory input) and then is transformed into an image by the brain that can be interpreted and recognized as perception (output that is “built-up” from processing to final knowledge). In a bottom-up approach, the individual key components of the system are first defined in detail. These elements are then interconnected to form larger sub-systems, which in turn are connected, sometimes at multiple levels, until a complete top-level system is formed. This strategy often resembles a seed model, in which the beginnings are small, but eventually develop into complexity and completeness. However, “organic strategies” may lead to a tangle of elements and sub-systems, which are developed individually and subject to local optimization as opposed to achieving a global goal.

System designers and engineers rely on both a bottom-up and a top-down approach. The bottom-up approach is used when selecting and incorporating into the product off-shelf or existing components. An example would be to select a specific fastener, such as a bolt, and design the receiving elements so that the fastener fits properly. In a top-down approach, a custom fastener will be designed to fit the receiving components correctly. In terms of product perspective, for a system with more restrictive requirements (i.e., weight, geometry, safety, environment), such as the rail system, a top-down approach is followed and almost everything is custom designed. However, when it is more important to minimize costs and increase the availability of components, as with construction equipment, a bottom-up approach will be followed and as many off-the-shelf components as possible will be selected. In the latter case, the receiving housings will be designed around the selected components. The development of systems engineering requirements is the improvement of systems requirements and the creation of a basic platform that will validate the understanding of customer needs and their coverage by the proposed solution. The tasks to be performed at this stage are defined as:

·       Transforming customer needs and expectations into requirements that are clear and verifiable (i.e., functional, operational, and architectural requirements).

·       Performance gap analysis with reference solution.

·       Improving the proposed solution and allocating the requirements to the system components.

·       Confirmation of traceability.

·       Development of systems testing requirements.

 

The input data of the systems’ requirements development shall include the:

·       Contractual documents.

·       Conceptual design documentation.

·       Preliminary safety hazard analysis.

 

The output data of the systems’ requirements development will include the:

·       System requirements (i.e., functional, operational).

·       System architecture.

·       Interface control documents (i.e., external, internal interfaces: preliminary version).

·       Gap analysis report.

·       Clause-by-clause analysis of the latest revision.

 

The control phase report, for the development of system requirements, shows the traceability of the relevant documents developed during the design and build phases, according to the requirements of the contract. The gradual development of system engineering requirements is processed during the design process (i.e., concept, preliminary and detailed design). These requirements will be further enhanced in the next phase of the final design and build process, where the system traceability of the system requirements will be accurately identified.

The functional system requirements specify an exhaustive list of functions that the proposed system must perform. The determination of the functions of the operational requirements of the system will result from the documents representing the contractual requirements of the project, as well as from the technical provisions submitted by the client through the various entry documents. This analysis will be performed with a structured top-down analysis of the basic functions of the system. Each function will be divided into lower-level functions. This analysis is an iterative process that stops when each function can be allocated in a sub-system. This analysis covers normal and degraded railway system operations. For example, the input data of rail operating system specifications will include:

§  Contractual documents.

§  Technical provisions documents.

§  Railway system requirements.

§  Railway system architecture.

 

The output data of the system specifications will include the operating system specifications and the traceability matrix update. The control phase report of the functional requirements of the system shows the traceability of the relevant documents that will be developed during the design and build phase in relation to the contractual requirements. The final validation of this document should be reviewed by systems engineering and the technical managers of the various sub-systems. The modes and principles of operation of the systems describe the behavior of the system in terms of operation, at system and sub-system level. Defining the operating modes and principles of the system will determine the interfaces between the system and the operators. The following operating modes and operating principles of the systems cover the scope of work:

·       Definition of the operating system of the railway system in normal and degraded functions.

·       Rail system transport and routes.

·       Normal operating modes and operating principles of the system both in the mainline and in the maintenance and storage facilities (when applicable).

·       Degraded modes in mainline and maintenance and storage facility.

·       Emergency situations.

 

The operating modes and operating principles of each system must be checked against the relevant functions to ensure consistency with the functional requirements of the system. These will be used by the operator to generate the operating procedures. The input data of the system’s operating modes and operating principles are included in the contract documents, engineering concept papers, system requirements, system architecture, safety, and RAM requirements. The output data, of the system’s operating modes and operating principles will provide the system’s operating modes and operating principles definition, and the update of the traceability matrix.

The control phase report of the system engineering modes and operating principles is required to show the traceability of the relevant documents to be developed during the design and build phase according to the contractual requirements. The final validation of this document should be reviewed by the system manager and the technical managers of the various sub-systems. The phase of the functional requirements of the system will take place during the detailed design.

The identification of the system architecture applies the operational requirements set in the system’s operation mode. The identification of the system architecture will include the description of a system in terms of architecture and physical elements that will meet the requirements of the functional specifications and the breakdown of a system into sub-systems in relation to their respective sector. The input data of a system architecture ID includes the operating system specifications, the requirements for the rail system, the rail system architecture, and the definition of operating systems and operating principles. The output data of the system architecture definition will provide the system architecture definition, including the product breakdown structure and the internal and external physical interface identification, as well as the traceability matrix update. The control phase report of the system architecture definition principles is required to indicate the traceability of the relevant documents to be developed during the design and build phase in relation to the contractual requirements. From a technical point of view, the architecture of a basic system will include all relevant sub-systems, such as the main functions performed in the complete system, the organic interfaces that will be differentiated from the functional interfaces, and the main features of the architecture; and the identification of the interfaces to be managed between the sub-systems of the system as well as between the system and the external environment.

For example, the main sub-systems included in a rail system are: (1) Traction power (e.g., supply and distribution); (2) Rolling stock (e.g., traction and brake systems, auxiliary power supply including the auxiliary power converter, door control including the low voltage supply and actuators, driver’s cab including the instrument panel, electrical cabinet and safety instruments, heating, ventilation, HVAC system, and additional on-board equipment such as communication and signaling); (3) Trackwork (e.g., track infrastructure, and track superstructures); (4) Buildings and wayside distributions (e.g., building power distributions and maintenance facility power distribution); (5) Communication sub-system (e.g., fixed telephone system including emergency telephones, passenger information telephones, public telephones, administrative telephones, fire telephones, mobile radio services including OCC (Operations Control Center) radio, hand-held radios, PA (Public Announcements); station PIS (Passenger Information Systems) including OCC workstations, stations screens, and on-board displays interfaced with the signaling system, station VBS including high quality video screens, station media players, and content manager server, backbone transmission network including optical fiber or copper or coax, carrier line transmission network and centralized network management system, CCTV including wayside screen monitors and wayside cameras, time distribution including OCC main master clock and stations and OMSF local master clocks, and communication cables); (6) AFC (Automatic Fare Collection) services (e.g., OCC, ticket office machines, station control units, sliding door gates, hand-held equipment and cables); (7) Maintenance (e.g., rolling stock depot equipment, test track equipment, maintenance tools and test equipment, work trains and road vehicles, MMIS (Material Management Information System)); (8) Train control system or signaling sub-system (e.g., trackside components such as IXL, ATP, ATS, ATR, train-borne equipment, cables, and SCADA (Supervisory Control and Data Acquisition)); (9) OMSF (Operations, Maintenance, Storage, Facility); and (10) the BACS (Building Automation and Control System).

Overall, the railway system architecture can be described into three parts: (1) Description of the sub-systems (i.e., main functions, main equipment, and architecture); (2) Preliminary interface analysis; and (3) System architecture scheme.

Systems Engineering Modeling (SEM) is a monocentric model designed to:

§  Facilitate the system engineer’s dilemma on complexity and synchronization.

§  Facilitate the rail systems understanding with regards to system design, construction, and engineering project management.

§  Aid in decision making (i.e., “what if scenarios”); explain, control, and predict events.

§  Save substantial money and time by identifying omissions and defects during the analysis and design stages.

 

SEM is a set of sub-models that can talk to each other and store data. The main feature of SEM is that it is used to enhance the organization of the railway system during the design, construction and verification and validation stages. This means that SEM covers all domains of systems engineering along with their requirements. In addition, the SEM includes additional functions such as trade-off studies, program and engineering changes, quantitative risk analysis and management. In the SEM model there are four main domains of systems engineering:

1.     System requirements domain that includes all the functions, performance, constraints, and requirements that the rail system must meet in order to function as planned.

2.     System behavior domain where the engineer determines what the system will do to meet all the requirements. Thus, this is a list of functional activities that must be performed by the system engineering model.

3.     System architectural domain. This is a set of components (e.g., hardware, software, people, and processes) that work together to perform defined behavioral functions. Of course, each component of the system will have certain behavioral functions allocated within it, and each component will have interfaces that will be part of the architecture linked to other design components.

4.     System verification and validation domain. Systems engineering is responsible for ensuring that each component of a sub-system of a system will do what it is programmed to do and therefore meet the needs of the user.

 

The above domains must be interrelated. This means that this information must be directly interconnected instead of being stored in separate documents or spread sheets in different databases. The goal of SEM is to maintain all these relationships, of the various databases, within the monocentric SEM database. Currently, the design of a system uses individual databases, see Figure 26, for each of the four domains. It is evident that the utilization of independent databases forces the manipulation and labor of extraordinary data management which has as result a complication on the system’s engineering tasks and between the four domains that result in design defects. The solution to the above problem is to create a platform based on a monocentric model that will capture data from all independent databases of the identified domains. By implementing this modeling solution, the systems engineering approach gains the benefit that any changes will be immediately spread across the domains due to the absence of stove and piping domains.

Thus, a single model platform will be able to integrate all these different types of information into a single repository. This unified model platform, as shown in Figure 27, can assist the systems engineer to perform accurate system-based engineering analysis based on digital analysis.

Systems analysis helps engineering integration strategy teams to harness their data and use it to identify new opportunities. Specifically, information technology has become an integral part of all major processes in the development of any system engineering project. Consequently, all the data necessary for the measurement should be obtained from the same database used to perform the system process to be measured, following a “single source” philosophy of truth. A comprehensive analytics platform basically increases the amount of information available to decision makers as well as helps them understand the information available. Under a systems analysis platform, decision makers can have more information and therefore more choices, from which they can draw more accurate conclusions. Additionally, there are a variety of tools available for exploring, visualizing, and understanding the data available in relation to any complex trade-off space, rooted in the SEM platform, which in sequence can provide a timely picture of the impact of decisions that range from technical solutions to complex public policies.

The analysis and processing of this data falls within a wide scope of the systems analysis platform. However, in our experience, there are three main categories of system engineering analyses of related problems associated with KPI measurements in practice.

1.     Heterogeneous application and data landscapes: where data is obtained from different non-harmonized data sources and analyzed using different applications.

2.     KPI Inflation: Due to the small amount of effort required to recover KPI through system analysis, some system engineers use more than 100 metrics to manage parts of a project, losing sight of what these metrics mean and how they relate to each other – without making a proper distinction between an operational report and a key performance indicator.

3.     Pseudo-accuracy: especially when the first two problems apply, the accuracy of the KPI becomes questionable and prone to intentional data measurement. However, these inaccuracies can be difficult to identify. If the recipients of the KPI reports do not suspect this, they may be led to incorrect system decisions. If they suspect this, then they may lose confidence in the KPI, rendering the whole solution useless and therefore the system analysis useless.

 

From the point of view of change management, the implementation of the KPIs in the field of systems engineering analysis should be done gradually and be accompanied by strong guidance and training of project engineering. In terms of systems engineering project management data, as each project is very different and fits differently into an organization’s strategic map, the critical factors to be measured vary from project to project. However, there is agreement on some principles for selecting KPIs for project management, which are related to time, budget, and scope. To make a system analysis useful, the KPIs for project management should include non-financial measures, be measured frequently, be implemented by the system managers, state clearly what actions are required by staff, introduce measures that link responsibility to individuals and teams, have a significant impact, and encourage appropriate action.

Systems engineering design must also be measured, according to the delivery dates, and within the agreed design requirements, and budget. In fact, systems engineering usually takes place as a single process which consists of a set of coordinated and controlled activities with start and end dates, and undertakings towards a goal that meets specific requirements, including time, cost and resource constraints.

Thus, a systems analysis platform in conjunction with SEM followed by appropriate training and experience leads to smarter budget moves, more efficient design processes and operations, higher profits, and happier customers. Specifically, the system analysis platform can offer value in the following ways:

1.     Cost reduction regarding big data technologies and cloud-based analytics bring significant cost benefits when it comes to storing large amounts of data – as they can identify more efficient ways of doing business.

2.     Faster, better decision-making with the speed of today’s data technologies and analytics combined with the ability to analyze new data sources, systems engineers can analyze information instantly and make decisions based on what they have learned.

3.     New system products and services with the ability to measure project needs and satisfaction through analytics provide the power to give customers what they want.

 

Systems engineering data analysis also includes search engine optimization where keyword search is tracked, and this data is used for engineering purposes. Systems engineering data analysis is generally divided into exploratory data analysis, where new features may be discovered in the data, and confirmatory data analysis, where existing assumptions turn out to be true or false. The accuracy and efficiency of the output data of systems engineering are based solely on the simultaneous application of statistics, computer programming and a good understanding of the whole package of all system engineering disciplines involved along with the financial concept in order to quantify performance and the health of the project. Systems engineering data analytics is based on more than 100 database analytics features, which support analytics where data eliminates costly data traffic and delivers industry-leading performance while hiding the complexity of parallel programming. The output of systems engineering data analysis allows prediction and scoring within the SEM database.

Another benefit of the SEM database is that we can design a system in layers. The implementation of this approach requires to lay-down, at a high level, the requirements, behavior, architecture and the verification and validation of the systems requirements, then link all the information into the first level and then through a top-down approach we will be able to proceed into an in-depth analysis on each component inside of our design. In the case of the design layer approach, the SEM model is very valuable because it is different from any other traditional technical approach and often creates ambiguity and inefficiency in managing complexity, interfaces, and communications. This leads to a waste of time and cost, miss-communication between people, and interpreting the “Truth” differently. Figure 29 illustrates a system design in layers based on the four-domain SEM model and a top-down approach. The system designer in this case must consider the following two constraints:

1. He must complete a layer before he will be moving into the next layer.

 

2. He cannot iterate back more than one layer. 

Below, Figure 30 illustrates how a SEM model views are developed by using a top-down approach by starting from the requirements domain. Systems engineering concentrates on defining customer needs and required functionality as early as possible, then follows the design and validation, while considering the whole problem. Systems engineering adds the most value to a project when there is clarity over the system engineering roles and responsibilities.

 

A well-planned system activity will ensure the right balance of stakeholders’ needs between time, quality, and cost. The following system activities, see Figure 31, are usually planned to be performed during the project’s three phases: (1) Concept engineering phase; (2) Design and build and delivery phase; and (3) Operations and asset management phase.

The general objectives of systems engineering are to demonstrate that they can be used to build better systems, where this can be achieved through some measurable improvement parameters, and also, they can achieve a better understanding of how to adapt systems engineering for the purpose to achieve optimum result in a rail project.

 

It is a common phenomenon that during construction and integration the system engineers and project managers in mega-projects must deal with a plethora of budget gaps along with design and construction defects due to the lack of continuity and specificity. Specifically, system engineers and project managers everyday are experiencing the connection between costs and defects as they go down the design-build-operation and maintenance life cycle of the project.

It is very inexpensive to correct all these defects during the analysis and/or design whenever you need to make a change somewhere. Yet, as you start to construct and test, and install a system in the field then the cost for fixing the resulted defects goes up dramatically, see Figure 32.

Systems engineering experts can design a system on levels, and then decide to dive deeply into the individual elements inside the system design.

 

The design layer approach is very valuable because the SEM model is very different than any other traditional engineering approaches. And although the engineers can actually achieve a level of granularity during the top-down approach in various areas, yet they are still able to simulate the system at higher levels. Yet, always pops-out the question on how do we identify the defect(s) during the analysis and development of the various design stages, since most of the defects are not observed until will get into the integration of the whole system and sometimes even pass that? The answer to this concern is that when we have a set of relationships that are worthy of the SEM domains and therefore, we can perform a series of diagnostics to ensure that our relationships are present, so we check to see things such as: incomplete interfaces, unallocated behavior, unimplemented requirements, unverified requirements, unaddressed risks, and undocumented elements. Thus, finding not a defect but a design omission during the analysis then that it will prevent a defect from appearing downstream in integration. Therefore, through the SEM model we can achieve substantial value through all these relationships, and we can run reports that can identify any broken or missing relationships in the design.

The SEM model, along with the systems analytics and systems integration are of great importance to system engineering projects in any industry because they provide numerous benefits in the areas of DBOM (Design-Build-Operate-Maintain) and productivity.

Specifically, through the SEM model we can achieve:

§  Improved DBOM can be achieved by providing immaculate design optimization, implementing high quality engineering and program management, applying engineering sophistication towards the contract’s deliverables, introducing rigorous traceability between requirements, carrying through efficient implementation into the systems architecture, applying strict verification and validation, enhancing design coherency and consistency  between all the different sub-systems, and providing rigorous management of design change and system architecture configuration.

§  Increased productivity can be achieved by implementing the reuse of the existing rail system of sub-system models to support design evolution, reducing time and errors during integration including verification and validation, enabling concurrent system architecture definition, generating documents and reports automatically from the system engineering model.

§  Reduced risk development that can be achieved by applying strict traceability between requirements, implementation to systems architecture along with verification and validation, accurate system development cost estimation, and accurate system architecture impact analysis against requirements changes.

§  Improved communications that can be achieved by introducing a common understanding of system analysis and architecture across the development team and other stakeholders and the ability to integrate system views from multiple perspectives.

§  Improved transfer knowledge can be achieved by providing system architecture and option justifications reflected in a standard format that is easily accessible.

 

The SEM model should be considered the main cornerstone for systems development. This is because, the SEM model provides us with all the necessary tools and sub-tools that can allow the system contractor to make his deliverables according to his contractual commitments, while at the same time he can provide the best possible services to the customer. During the design and construction of a system, some ambiguities, and defects in the specifications of the system requirements can have a direct impact on the development of the whole system and therefore on the safety of the system. For this reason, there are many standards such as: European Standards (EN50126, EN50128, EN50129) and International Standard (IEC61508) that can help us to obtain safety evidence in the system specifications. However, it is crucial to comprehend that these standards often specify what needs to be done but provide very little guidance on how to implement system requirements in various projects (O. Nordland, 2001). Thus, in order to define a system and follow safety strategies, many different techniques and methods must be applied. Furthermore, the aim of achieving a homogeneous and consistent system specification is to clarify the syntax and semantics of the technical specifications and modeling used. This means that the checking capabilities that ensure the accuracy of the safety requirements, together with the logical interaction between the different techniques applied and the way they are supported, must be crystal clear.

At this point we will focus specifically on developing system specifications in terms of meeting standard requirements. Typically, there are four types of stakeholders involved in the system specifications and these are:

§  Operating authorities or customers (prepare system specifications or pass them on to manufacturers / suppliers or in collaboration with system developers).

§  System developers.

§  Supervisors or safety authorities (should inspect the system specifications and ensure that they comply with the specified standards. However, they often pass the inspection to evaluators who are independent experts in the field of implementation).

 

After accepting the system specifications, it is given to the system developers, who will realize the system specifications in the role of supplier. But before anything else, they need to understand the requirements of the user. Proper understanding is tested in this way so that developers are able to articulate the requirements more accurately in the form of system design specifications. On this basis, the operating authority / client can check if the system developers have correctly understood the requirements of the users. The conclusion is that when developing system specifications safety not only needs to be achieved, but also needs to be proven to the supervising authority. Such a demonstration is the basis for the approval of the system specifications. This means that it must be clear to the inspectors of the supervisory authority/safety authority how the safety is achieved. Therefore, the various methods and techniques applicable must be understood by the inspectors.

The main issue with IEC61508 is that absolute safety cannot be achieved because absolute safety is not an absolute value and therefore safety should be defined as a judgement of the acceptability of the risk for danger. A system is safe if the consequent risks are considered acceptable. Therefore, the risks, which are not tolerated, must be reduced. Operational risk is a situation in which there is a threat to humans or the environment, caused by the operation of the system, which may lead to an accident. The risk is greater than the marginal risk. This can arise from the system itself or from its environment. In contrast to previous types of system specifications, European standards EN50126, EN50128 and EN50129 require the determination and prescription of safety target for integrated sub-systems as part of the system specifications as well as the security target for multiple sub-systems. As a prerequisite for achieving this, the defined standards require risk analysis in the context of preparing the system specifications.

The risk analysis identifies potential operational risks, which must be taken into account in the development of the system with countermeasures. Proceeding from this basis, the possible consequences of operational risks are analyzed. On this basis, tolerable risk rates can be calculated. In this way it can be checked whether evidence of similar safety is obtained. In this way quantitative risk values can be determined. In the further steps of system development, it must be borne in mind that these values are not exceeded. Along with the various standards, the system designer should keep in mind that the use of “Formal Methods” to demonstrate safe functionality is highly recommended for high safety demands. Formal methods are techniques used to model complex systems as mathematical entities. By building a mathematically rigorous model of a complex system, designers can not only verify the system’s properties in a more thorough fashion (than they could via empirical testing) but also use mathematical proof as a complement to system testing so as to ensure correct behavior. Formal methods adopt a three-step approach to modeling and evaluating systems. During formal specification, an engineer or designer rigorously defines a system using a modeling language – typically by using a formal, mathematical syntax and semantics that eliminate imprecision and ambiguity. This is similar to writing down system specifications, though not in plain English. From there, based on the specification, the engineers develop a set of theorems about the behavior of a system. These theorems are verified through mathematical proofs – to ensure that the system behavior is logically consistent and is, indeed, the desirable one. As this allows designers and engineers to discover flaws in usability even before the design gets implemented into code, it prevents costly errors from emerging in the later stages of development. Finally, once the model is specified and verified, implementation can begin via converting the specification into code.

Formal methods (Figure 33) have many advantages: they help disambiguate system specifications and articulate implicit assumptions. They also expose flaws in system requirements, and their rigor enables a better understanding of the problem. Because they use a formal language, many system engineers can verify the specifications independently – thereby solving errors early on in the development process. However, formal methods cannot fully replace standard quality assurance methods. This is why they are just a complementary technique in system design. For example, railway interlocking system is a safety critical system. Its failure can cause the loss of human life, severe injuries, and loss of money. Therefore, the complication of this type of system requires advanced methodologies, which provide complete safety and quality of a system. One way of achieving this goal is by using Formal Methods.

 

Hence, the standards recommend the use of formal methods at least for the software parts of system specification in case of high safety critical systems, but it is highly recommended for the highest safety integrity level. However, from the point of view of certain supervising authorities there is the approach to use formal methods for compound system aspects (K. Kamel, K. Lennartz, K. Suwe, 2000). 

In addition, a Formal Method modeling of the system leads to a more compact and less complex system specifications. In IEC61508 temporal logic is characterized as suitable for direct expression of safety requirements and as a basis for formal demonstration that the expressed properties are maintained at different stages of development. The consequence is that already in the system specifications the system must be accurately described in the form of a system model and the safety requirements must be described as part of the system specifications. According to the considered standards, it is proposed to apply a correctness check180, instead of a consistency check181, for all scenarios as well as for most of all kinds of requirements. The cost of performing correctness and consistency checks is not reasonable in every case when is compared to its benefit. Only for high safety-related functional requirements and critical high-safety operational scenarios, these methods are useful.

 

According to the standards under consideration, it can be concluded that risk analysis and demonstration of safe functionality are two key activities for the development of system specifications, as shown in Figure 34. For both activities, a precise system model is the basis. The development of this model is the third activity. These three activities are the building block for safety evidence in the development of system specifications. It can be confirmed that the process of developing system specifications should support the performance of risk analysis and should allow functionality by identifying safety requirement, the formal specifications of safety requirements, and the formal checks for correctness and refutation.

The use of Formal Methods182 in system development for safe systems is still rare. A significant predicament is that many formal software languages and formal analysis techniques are unfamiliar and difficult to understand and consequently difficult to apply for engineers. Thus, for those system developers, who in general are no experts in Formal Methods, the used notations and techniques should not be easy to understand, especially across the involved working teams. On that note, the assessors and the supervising authority must be able to understand the whole system model and the used techniques with regards to correctness checks to achieve safety. That means that they must be able to reconstruct correctness checks, otherwise they would not be able to accept system requirements specification.

Another important demand of the developers is the application of methods for system development (e.g., Waterfall, Agile, Lean, Iterative, Prototyping, DevOps183, Spiral184, V-model). If intensive training is necessary to introduce methodologies for system development, yet accepting new methods is difficult and raises doubts about the benefit. For these reasons, the existing methods, which are known to the system developers, or which are becoming more and more important due to other advantages, must be taken into account. The modeling notation must be understandable and the model structure easily recognizable. This leads to clarity, so that especially in teamwork the system model is easy for different people to understand. From an engineering point of view the model used for system modeling should be reusable for design. This means that the acceptance of a formal notation is low if it is different to the design notation. Today, in engineering graphic notations are increasingly common in stages of analysis and design due to their compact and intuitive comprehension. Progressively the Unified Modelling Language (UML)185 becomes a standard in system and software modelling in systems engineering.

The system model of a system specification ideally contains a description of operating scenarios, system structure, and sub-systems behavior. To perform the risk analysis, ideally there is a model of the system structure and executable models. This will support qualitative analysis. The executable model provides information on the immediate effects of the fault and based on the structure, model failure relationships can be identified for the system environment, system parts and sub-systems. Thus, the different aspects of system modelling can be achieved by using UML notations. Operational scenarios can be specified by means of sequence diagrams of UML. For modelling the system structure and interfaces between system objects then the use of class diagrams is suitable. For the description of the behavior of the system then the use of objects state charts is used. However, the condition for using UML diagrams for system specifications, which can be used for standard proofs and refutation tests, is that the UML must be used with precise semantics. For that purpose, first lacks clarity in semantics must be identified. Second a semantic foundation must be defined unambiguously for these lacks. This is possible by definitions of translation rules for the conversion of UML notation in a formal language, like it is used as input modelling language for model checkers. Model checking is a technique to perform correctness and refutation checks.

In accordance with EN50129 risk analysis essentially consists of four main steps: (1) System definition; (2) Identification of operational hazards; (3) Consequence analysis step; (4) Risk assessment. However, when a system is modelled based on UML then is ineffective to specify the system in the first step since this is a main requirement for the development of a precise system model. Thus, the more precise the system definition is then the more exact are the rest steps of risk analysis. Here, it is introduced an approach in which risk analysis is supported by notation of the system model. Specifically, it will be shown that UML system modelling aspects are ideal for carrying out risk analysis. On that basis the identification of operational hazards can be determined systematically by using Failure Mode and Effect Analysis (FMEA), see IEC60812, Fault Tree Analysis (FTA), see IEC61025 and by analysis of scenarios of the system operation. At FMEA the consequences of failures of sub-systems or failures of system functions are considered. These could lead to operational hazards, which are determined by a sequence of effects of such failures. Given of the applicable regulations, standards, and expert knowledge in systems it can be decided, which top-level system failures derived by using FMEA may be relevant as operational hazards. The result of the FMEA can be checked by using FTA. The consideration of scenarios, in which failures occur, helps in determination of hazardous situations. This way it can be analyzed in which cases operational hazards occur. Those scenarios can be performed with help of UML sequence diagrams.

The first step of FMEA is a description of the system structure. This is done, by dividing the system in sub-systems. The second step is the assignment of system functions to the several determined sub-systems. On that basis possible failure functions can be determined to every system function.

These failure functions are the basis for the data for the analysis of failure consequences and failure correlation. These analyses can be supported by the system definition in form of the UML model. System and sub-systems of FMEA can be derived from the objects of the UML models. Failure consequences and correlation can be indirectly gained by the information of the UML model concerning the correlation of system functions. In UML State-Charts186 and in these sequence diagrams, which describe interactions between system objects, the causal and temporal system behavior can be found. This gives information concerning possible failure correlation. Especially the consideration of scenarios, in which failures occur, helps in the determination of hazardous situations. Thus, the main creative part of the FMEA is the determination of possible failures of sub-systems and of the functions of the system and the analysis of possible consequences of failure.

 

The effect of the FMEA can be checked by analyzing the opposite way by using FTA. This means, that due to operational hazards, failure causes of failures of sub-systems or failures of single actions, which lead to these operational hazards.

‘Engineering Excellence DNA in Applied Systems’ by G. Ardavanis – 27/01/2024

Tags :
Share This :

Leave a Reply

Your email address will not be published. Required fields are marked *