Systems Engineering Course Notes

(1). A system is a complex set of many often-diverse parts subject to a common plan or serving a common purpose. A system is something that provides a solution to a complex problem.

A system must meet some defined need, goals and objectives, which must be clearly stated by the user, and represent the stat point of the design process as well as the ultimate test of the system’s fitness for purpose once it has been introduced into service.

(1b). A system is often described in terms of such resources as:- personnel,- materials,- facilities,- data,- hardware,- Software.

Analysis of these resources yields the majority of the system’s functional and performance requirements.

(2). the life cycle of a system commences with the statement of a need and ends with the disposal of the system. In between there are a number of system phases and activities.

The Blanchard and Fabrycky model is below:

Two main phases in the above life cycle. They are:

1. Acquisition Phase (Conceptual Design to Construction)2. Utilisation phase.

The acquisition phase is from the input of a need and continues until the system is put into service. The utilisation phase is the operational use phase and concludes at disposal.

The acquisition phase comprises of four main activities of conceptual design, preliminary design, detailed design and development, and construction and/or production.

The Conceptual Design is the initial systems engineering effort aimed at producing a clearly defined set of user requirements at the system level.

The aim of the Preliminary Design is to convert the functional baseline into a preliminary definition of the system configuration or architecture.

Detailed Design and Development involves utilising the allocated baseline developed in the preliminary design to commence development of the individual subsystems and components in the system.

The final activity in the acquisition phase is Construction and/or Production. The product baseline produced in during the Detailed Design and Development will have been refined and finalised prior to entering this phase. System components will be produced in accordance with

the detailed design specifications and the system is ultimately constructed in its final form. Formal test and evaluation activities ill be conducted to ensure that the final system configuration meets its intended purpose.

The final pase of the life cycle is the Utilisation Phase. The activities involved are the operational use and system support. Systems Engineering may continue through this phase to support any modifications.

(3). The Key foccuses of Systems Engineering.

1. Requirements Engineering. - Complete and accurate definition of requirements is central- Original need translates into statements of requirement, which form the basis of

functional and eventually physical design.- These translations must be managed- The process is sometimes called requirements management, requirements

engineering or requirements flow down- Traceability is also critical.`

What is traceability?Design decisions can be traced from any given system-level requirement down to a detailed design decision (forward traceability). Also any individual design decision must be able to be justified by being associated with at least one higher-level requirement (backwards traceability). This process assures the customer that every requirement is accounted for in the design stage.

2. Top-down Approach.Traditional engineering design methods are based on bottom-up approach. i.e. known

components are assembled into sub-systems which then constructs the system and then tested against requirements. Not good for complex systems. Top-down looks at the complex system as a whole, this does the following:

- Provides a thorough understanding of the system and its environment and interfaces.

- System-level requirements are developed- Emergent properties are identifiedThe likely physical subsystems can then be considered and requirements assigned to individual subsystems:- Additional derived requirements are also developed.- Interfaces between subsystems are also identifiedThis process is continues until reaching a logical end point.Design is top-down but implementation via integration and testing is still done in a

bottom-up manner.

Top-down approach.

3. Life-cycle focus- Systems engineering maintains a life-cycle focus as decisions are made.- Often, people focus on acquisition issues and lose sight of life-cycle issues

o Minimise acquisition costs and schedules- Losing concentration on life cycle issues often leads to decisions that minimise

acquisition cost &/or schedule however adversely affect utilisation costs.- This fact is exacerbated due to a system spending most (hopefully) of its life in the

utilisation phase.

4. System Optimisation and BalanceIt does not necessarily follow that optimised sub-systems leads to an optimised system.The system architecture must represent a balance between the large number of requirements that, as well as the technical considerations, cover a wide range of factors such as: - Moral,- Ethical,- Social,- Cultural,- Psychological et al.This is achieved as a by-product of the design process i.e. the top-down approach. Also allows cost-effectiveness to be measured across all phases not just the acquisition phase.

5. Integration of specialities and disciplines.System engineering aims to manage and integrate the diverse range of technical disciplines and specialities. These include but not limited to the following; finance, legal, environmental specialists, marketing etal.

The integration of these specialists and disciplines is integral and critical to the success of a complex system.

6. ManagementSystems engineering is highly technical and provides essential methodologies for systems development however is not limited to just technical and is not just simply an engineering process. Has a very important management role to play.The functions of Project Management and Systems Engineering are vital ensure the system is delivered on time and within budget and meets the customers need.Systems engineering ensure the project management decisions are informed.

(4). Benefits.

Scope of saving money during all phases of the system life cycle—life-cycle cost (LCC) savings. Assist in reducing the overall schedule associated with bringing the system into service.Ensures the user requirements are accurately refelcted in the design of the system.Minimises costly and time consuming changes to requirements later in the life cycleReduction in the technical risks associated with the product development. Risks are identified early and monitored throughout the process using a system of technical performance measures and design reviews and audits.Leads to a product that meets the original intended purpose more completely.

(5). Functionally and Physically.A systems functional description articulates what the system will do, how well it will do it, under what conditions it will perform and what other systems will be involved with its operation. A systems physical description relates to the system components and explains what the components are, how they look and how the components are to be manufactured and integrated.

(6). Explain “Cradle to Grave”.Systems engineering can be desribed as “Cradle to Grave” in relation to the life-cycle

which starts with a need from the user (Cradle) through to disposal of the product after utilisation (Grave).

(7). In term of life-cycle costs, explain the interest in the Utilisation phase.In terms of life cycle costs, Systems Engineering is interested in the Utilization Phase of a system life cycle as this phase encompasses the costs of use, modification, support and disposal. These costs are more difficult to determine than Acquisition Phase costs, representing greater risk to the engineering of the system and therefore receive attention proportionate to this risk.

(8). As an Acquirer and Supplier explain application of systems engineering methods to each taskAs the acquirer of a system you would apply Systems Engineering methodology to your tasks IOT ensure that the system is adequately defined, operated and supported. As the supplier of a system you would apply Systems Engineering methodology to your tasks IOT ensure that the system is adequately defined, analysed, specified and manufactured.

(9). Explain Analysis, Synthesis and Evaluation process.

Analysis. Analysis commences with a statement of perceived need or a set of customer requirements. The analysis activity resolves what is required, as well as how well and why. Analysis activities continue throughout subsequent stages of the lifecycle to help in defining lower-level requirements, often called derived requirements, associated with physical aspects of system design.

Synthesis. Synthesis is the process whereby technology and creativity are utilized to produce a design that best meets the stated system requirements. In the early stages of the SE process synthesis is limited to defining the functional design of the system and considering all possible technical approaches using results from the requirements analysis effort. Later in the SE processes, further synthesis is applied to the selected design concept until the system design is finalized.

Evaluation. Evaluation is the process of investigating the trade-offs between requirements and design, considering the design alternatives and making the necessary decisions. The process of evaluation continues throughout all stages of the systems engineering effort and determines the systems satisfaction of user requirements. The outcome of evaluation is a selection or confirmation of the desired approach to design.

(10). Systems Engineering is often perceived as adding complexity , cost and time to projects this is due to the rigour of initial thought and work done in the Conceptual Design phase through the whole acquisition phase however this rigour and strong processes and methodology ensures the end user receives a product that meets the original intent with traceability and hopefully less utilisation costs due to risk management processes involved through the design and production phases.

Chapter 2 Review Questions

(1) Outline the SRD and differentiate between the System Specification.

The Stakeholder’s Requirement Document (SRD) outlines stakeholder requirements. The SRD can be given a number of different titles, including the following:

- Occupational Concept Document or Description (OCD)- Concept of Operations (COD)- System Design Document (SDD)- User Requirements Document (URD)- Or simply User Requirements.

The SRD must consider all aspects of the system over its entire life cycle—operators/users are only one set of stakeholders. Others include, production, logistics, management, legislators and others.All stakeholders must be involved in the process.Needs to be written in the customer’s languageHas to be unambiguous and comprehensive in content.

The System Specification contains more formal requirements statements that is translated from the SRD by Systems Engineers. This documents forms the Functional Baseline of the system.

(2). Describe a Context Diagram and show how the diagram could be used through early stages of Conceptual Design.

Definition of the system boundaries is also critical to the success of the system. The boundaries need to be defined early in the acquisition phase so it is clear which system elements are under design control of the project and which are outside the control.The scoping process is assisted with a tool called a CONTEXT DIAGRAM which may be used to illustrate the related systems, relevant regulatory environments, stakeholders, external systems, interfaces, et al. The ACME Aircraft example is on the next page:

Simple Context Diagram Example

(s)

Stakeholder(I)

Interface(C) Constraint

ACME Air (S)Ground Crew Air Crew MaintenanceFinance Design Logistics Marketing

Third party Manufacturers (C)- Engines (c)- Avionics (c)- Tyres (c)- Navigation Systems (c)- Communications (c)

Passengers (c)

Regulators (C)- Noise (c)- Emissions (c)

Competing Aircraft (c)

Aircraft Manufacturers (c)Design Manufacture

ATC (I/C)- Communications (i/c)- Identification (i/c)- Control (i/c)

Airports (I/C)- Docking (I/C)- Refueling (I/C)- Landing Systems (I/C)- Navigation Systems (I/C)- Runways (C)

AIRCRAFT SYSTEM

Operating Environment (C/I)

(3) What is the difference between “user” language in the SRD and “specification” language in the System Specification. Provide three examples of each for a motor vehicle system.

The SRD must be written in the language of the user and customer as opposed to the more formal specification language employed in other systems engineering documents. In many cases the difference is because the user is operationally focussed and uses very little technical language. The SRD is always comprised of more natural language which is generally more easily read and understood by all stakeholders particularly the end user and customer.

Systems Engineers then translate the SRD into more formal requirements statements contained in the SS and forms the Functional Baseline.

Example of language for a Motor Vehicle System.

SRD Language SS Language1.The motor Vehicle is to be capable of operating on the standard Australian road.

The vehicle is to have a robust suspension system.

2. The motor vehicle is to be capable of achieving 10000 kms before requiring a standard service.

The vehicle is to have high quality engine parts

3. The motor vehicle is to be competitive in the medium sized car market.

The vehicle is to fit 4 adults.

(4) Describe and conduct a system-level feasibility analysis.

Once the SRD has been approved and requirements have been identified and articulated a feasible solution to the stakeholders requirements now need to be confirmed via a System Feasibility Analysis. The analysis should concentrate on system-level solutions. There are four steps:

1. Identify system-level solutions capable of satisfying the need.2. Confirm the requirements in the SRD are achievable and, if not, note likely

level of achievement3. Evaluate potential solutions4. Recommend a preferred system-level solution.

Below is a Summary of the process

Need: Town A needs to transport pianos to Town B.

WTF!

1. Utilise existing logistics company (COTS).2. Lease truck as required. (modified COTS)3. Purchase removals truck and modify and develop new company

(5) Explain the difference between functional, performance and verification requirements.

Functional Requirements: Identifies the many different functions that the system needs to perform in order to meet the endorsed goal, need and objectives contained in the SRD. This includes maintenance functions.Example: 3.1 The motor vehicle should have a minimum seat area for 4 adults

Performance Requirements: The performance related parameters a system must achieve. They inform us how well the system is required to perform. Each functional requirement will have a performance requirement. Examples are speed, accuracy, acceleration, endurance, enviro performance.Example: The two front seats will comfortably seat an adult each with a minimum of 50 cm square seat area. The remaining seating (second or third row) can have the average 85kg adult touching when seated together.

Feasibility analysis

Need, goals & objectives

Identify alternatives

Confirm SRD compliance Note non-compliance

Evaluate alternatives

Make recommendations

Requirements analysis

Verification Requirements: This is the statement that informs how each functional and performance requirement will be tested and hence verified. They are written as you write the functional and performance requirement.Example: Function and performance to be tested by minimum seat area as 50 cm square and 38 cm square for back seating.

(6) List and explain three characteristics of a “good” requirement.

(7) Explain the value associated with a rational against each requirement.

Assigning rationale against each requirement will assist with the removal of ambiguity but more importantly will assist in situations where more than one person is involved in the requirements analysis over the course of the project.

(8) Explain why the below are poor requirements.

The communications system used in the design shall be capable of 100 Mbps throughput under high, medium and low load conditions.The requirement has unnecessary language and mentions certain operating conditions that are not needed as they do not impact on the desired requirement.The communications system used in the design shall be capable of 100 Mbps throughput

The air vehicle shall be capable of a maximum air speed of 600.This requirement is poor as it lacks specific details such as rate of measure (knots, Km/hr) and in what type of conditions and altitudeThe air vehicle shall be capable of a maximum relative air speed of 600 knots at 20000 feet.

The motor vehicle shall be capable of an average speed of 250 km/hr averaged over an 8-hr period.Used average twice. Average is a variable measured over numerous readings i.e in this case time.The motor vehicle shall be capable of an average speed of 250 km/hr sustained over an 8 hour period.

(9) List and explain two ways that a Requirements Breakdown Structure (RBS) assists with requirements analysis.

The RBS framework will act as a reference source during requirements analysis to ensure that all aspects of the system requirements are addressed and that important areas are not omitted.It allows multiple people to work on the analysis simultaneously as it allows the effective allocation of responsibility for sections of requirements to individuals.

(10) Briefly describe Technical Performance Measures (TPMs) and how they are used to support the systems engineering effort.

TPMS are quantitative criteria that the system must meet that are determined from the preceding documentation RBS, SRD, FFBDs etc. They are requirements that are key indicators of progress or contain elements of risk.

(11) Select an example that illustrates how TPMs can be used to assist the system engineering effort.

Refer to Pg 51 to 53, ACME aircraft example and rate of climb TPM

(12) Perform a two-level functional analysis on (b). organising and conducting a university graduation ceremony.

University Graduation Ceremony

SRD1. Graduates receive bachelor2. Guests are able to observe and hear ceremony.3. Guests, graduates and staff are to be seated comfortably4. Protected from the weather5. Provide small refreshments

Functional Flow Block Diagram

RSVPs from graduates

Transport Dean to venue

Purchase Certificate Material

Arrange Dean to present

Invites to ceremony

Select venue

Graduate receives Bachelor

Dean Presents Bachelor

Level of pass. Honours?

Transport to venue

Store Certificates

PackagePrint Certificates

Student Passes

(13) The System Specification is produced during Conceptual Design.

(A) Why is the document so critical to the remaining systems engineering effort? The SS is the system’s functional baseline and hence critical to the whole system. It is the source of reference for all the

subordinate specifications that are produced at later

stages through the design process.(B) What are the consequences of gross errors in, or omissions from, this

document? These errors or omissions will flow into the remaining design effort. The later these errors are discovered, the more expensive and time consuming the rectification becomes.

(C) What Baseline does this document define? The functional baseline.

(14) Explain why the Functional Baseline might change and describe the likely impact of the changes as a function of time.

The original Stakeholder Requirements may change or they were not addressed correctly or to the end users satisfaction. This will impact on the the time of the project as the Systems Engineering team will need to

start again with the new requirements.

(15) Traceability is a cornerstone concept in systems engineering. Explain the concepts and importance of forward and backward traceability as they apply to the System Specification.

Traceability allows the customer/user to trace backwards from the SS to the original and endorsed SRD requirements or vice versa. This extremely important as it allows you to clearly see that the Stakeholder Requirements are being properly addressed in the SS particularly during the System Design Review and before progressing.

(16) Select three engineering management issues and describe the questions that we need to answer during Conceptual Design.

i. System engineering requirements. System engineering requirements including test and evaluation expectations, configuration management requirements, documentation deliverables, tech reviews and audits, and adherence to certain engineering standards. These requirements need to be considered and included because they will dictate how the design and development effort will be organised and managed. Systems engineering requirements add expense and time to the project but should reduce the technical risks of the system development effort.

ii. Logistics. Logistics support concepts including maintenance levels, repair policies and organisational responsibilities. All traditional aspects of logistics including spares, transportation, warehousing, and data should be considered and included.

iii. Project Management. Organisational responsibilities for PM, Sys Eng, Logistics management and operations and support should be clearly articulated and defined. This is to ensure all stakeholders understand and know their responsibilities throughout the lifecycle of the system.

Develop preliminary physical architecture

Investigate system, subsystem,

derived requirementsInvestigate TPMs

Requirements allocation

Chapter 3 Review Questions

1. Briefly describe the difference between Conceptual Design and Preliminary Design.

a. Conceptual design: The first step in the Acquisition phase. Responsible for the expansion of the system definition from a short statement of need into a functional architecture that may be very long. It aims to articulate the need, including stakeholder requirements; to analyse and document the system level requirements from need; and to complete functional design of the system. Normally is the domain of the customer/user who is responsible and heavily involved. Customer needs to determine what the system needs to do and how well it is to do it.

b. Preliminary Design: The second step in the Acquisition phase. Normally undertaken by the contractor. Starts with the functional Baseline produced as a result of the Conceptual Design and continues to translate the functional requirements into design requirements. The result is the establishment of the Allocated Baseline. Activities within the preliminary design include: Subsystem requirements analysis, subsystem requirements allocation, subsystem synthesis and evaluation, and preliminary design review (PDR). It is the translation from functional design to physical design. Customer has a limited role, primarily monitoring, review and supporting contractor progress.

2. Briefly describe the requirements analysis process within Preliminary Design.

Aimed at continuing effort commenced in Conceptual Design to next level of detail. Begins with a review of System Specification and review of relevant Technical Performance Measures (TPMs). Detail must be sufficient to describe the major subsystems and their components within the system. This stage begins to convert the “what” the system needs to do to the “how” it will do it – commencement of translation of functional design to physical design.

3. Briefly describe the requirements allocations process within Preliminary Design.

The process of grouping or combining similar functions into logical subdivisions. Groups are based on preliminary physical architecture formulate by the designers. It is related to RBS (Requirements Breakdown Structure) but in prelim design the groups are based around a prelim physical architecture drafted by the designers rather than functional RBS headings. Assists designer to determine to determine design of major subsystems and components that will comprise the system – the configuration items.

Assignment or allocation of functions to physical Configuration Items (CIs) is the major focus of requirements allocation.

Requirements allocation describes what each CI must do in terms of function and performance.

4. What are derived requirements?

Pg 71. Requirements that are additional subsystem functions and requirements that are derived from the CIs and are designed to ensure that the CI will be capable of meeting the assigned system and subsystem reqts. They are derived from the need to satisfy a higher-level requirement

5. The preceding phases of Preliminary design provide subsystem-level synthesis process with a large number of subsystem functional requirements grouped logically together. Some of these functional requirements will be at odds with one another. Explain how the designers will use the concepts of trade off and design space to ensure that functional requirements are met or exceeded by the design.

The Design Space is the “Space” available in the performance of the subsystems which is available for trade-off purposes to ensure that the system achieves optimal performance, rather than the individual subsystems. In order to achieve optimal system performance the subsystems may need to perform at a sub-optimal level, the trade-off is the compromise that is to be made by the subsystem to achieve overall system performance. It ensures that the most important system-level performance levels are achieved as a priority.

6. Explain the relationship between an RBS and a WBS.

RBS is the Requirements Breakdown Structure. It is the requirements framework around which the functional design of the system is to be based. It is the system around which many systems level requirements are developed. The RBS is grouped by function.

WBS is the Work Breakdown Structure. It documents the work packages and products necessary to produce a system, including the work to design, develop and test the configuration items. The WBS is organised by physical project elements and contains other project related information.

The relationship between RBS and WBS is very similar to the relationship between the CI list and the RBS

7. Explain what is meant by the Allocated Baseline and explain the products of Preliminary Design that define the baseline.

The allocated baseline is the major product of the preliminary design. It contains the allocation of requirements to system components and the detailed product and development specifications (PDS).

Preliminary Design process consists of:

i. Subsystem requirements analysis,ii. Requirements allocation,iii. Interface identification and designiv. Subsystem-level synthesis (design),v. Preliminary design review.

Product of Preliminary Design include:

i. Specifications –contain system, subsystem and derived requirements for each subsystem. The specifications produced are:a. Development specificationsb. Interface control documentsc. Product specificationsd. Process specificationse. Materials specifications

ii. The collection of all necessary specifications produced during Preliminary Design is called the Allocated Baseline description of each subsystem, including how it interfaces with other subsystems.

8. Describe the three broad design options (including advantages and disadvantages) open to the designer when selecting the best design alternatives during Preliminary Design.

Ser Design Option Advantages Disadvantages

(a) (b) (c) (d)

1 COTS - Commercial of the Shelf. Equipment that is commercially available.

May meet or exceed the requirement

Likely to be readily available

Possibly cheaper Maintenance and

support arrangements likely to be in place

Problems with form, fit and function

Documentation provided likely to be less than a Product Specification

May need to ‘qualify’ equipment – this is time consuming and expensive

2 Modified COTS – Equipment that meets a majority of requirements contained in the Development Specification for a CI may be modified to better suit needs of designer

Similar to COTS Some maintenance and support may be voided due to modification

Effort required to modify (time, cost and technical risk)

Developmental Items – designed from the ‘ground-up’ to meet specific requirements and characteristics detailed in the relevant Development Specifications

Likely to match desired requirements precisely in terms of form, fit and function

Likely to require significant effort

Maintenance and support arrangements will need to be established.

May require significant levels of fabrication, assembly or production

Likely to require significant testing and ‘qulaification’

9. Explain why a systems engineer may have to force subsystem designers to accept suboptimal designs.

The goal is to achieve an optimised system that meets or exceeds the user’s requirement. To achieve this goal it may be necessary to trade off capability or forego design space within a subsystem. The integration of a component interface (CI) may also require a system engineer to force a subsystem designer to accept suboptimal design.

10. An allocation matrix shows the relationship between functional and physical design. Explain why this relationship is important to (a) the contractor responsible for design, and (b) the customer.

a. The allocation matrix assists project traceability. It combines both functional (requirements) and physical relationships. The allocation matrix is a powerful toolwhen changes to either the functional or physical design are proposed. The effect of a change can be quickly determined.

b. For the designer the allocation matrix shows him/her what requirements and functions have been assigned to his CI. The designers derive additional subsystem functions and requirements for their individual CIs to ensure the CIs will be capable of meeting the assigned system and subsystem requirements. The derived and higher-level requirements form the basis of the technical specification for that CI.

c. For the customer allocation the matrix shows how the designer proposes to meet his requirements.

11. list and briefly describe three types of interfaces that can exist between subsystems.

a. Physical interfaces – normally the most obvious, they need to exist in real terms. May be pipes, fibre optic cable, wiring harness etc.

b. Electronic interfaces – name given to the flow of electronic signals between two points. They may flow over a physical interface or make use of radio frequency transmission.

c. Electrical interfaces – normally associated with a physical interface of some sort of power cable or data cable.

d. Hydraulic / pneumatic interfaces – are the mechanical equivalent of electronic and electrical interfaces.

e. Software interfaces – relate to passing of data between different computer software CIs.

f. Environmental interfaces – form the interface between the system and the environment. Interface is dependent on type of system, it is different for aircraft, skyscrapers, extreme conditions etc.

12. Explain the role of the ICD and an ICWG in the management of interfaces.

a. The Interface Control Document (ICD) is the primary means for managing the task of integrating different systems elements. It contains sufficient detail to define completely the interfaces between the different subsystems. The type of information varies depending on the nature of the interface.

b. Interface Control Working Group (ICWG) – the team(s) that bring interface definition and design together. They generate the initial ICD and then meet to address and review any ongoing issues. Product of these meeting are formal interface design issues and decisions, and updated ICDs.

Chapter 4 Review Questions – Detailed Design and Development

1. Explain the role of system prototyping (including examples of different types) used during Detailed design and Development.

The role of system prototyping is to verify the design concept and system configuration using the system components arranged, combined and integrated in a “final” state. This prototyping allows the system level requirements to be physically demonstrated in a defined test and evaluation regime.

Examples: Prototypes can vary from very complete and almost final versions of the systems in terms of form, fit and function through to models that only represent the functional characteristics of the final system. An example of the almost final version would be a ‘mock-up’ of a flight deck to using the actual instruments and wiring harness to test an avionics system whereas the prototype to test the functional characteristics of the same avionics system would be the software networked on a number of desk-top computers.

A fire control system in an armoured vehicle. The almost final version could include the fire control system in a mock-up of the turret including the gun and communications system, whereas the test the functional characteristics of the same fire control system would be the software networked on a number of desk-top computers.

2. Describe the major review conducted at the conclusion of Detailed Design and Development.

The Critical Design Review (CDR) is the final review prior to official acceptance of the design and subsequent commencement of the construction and/or production phase. The CDR needs to be conducted on all CIs, either individually or within the system. It aims to demonstrate the CIs satisfy the functional and performance requirement assigned to them in the Product Specification. All Technical Performance Measures (TPM) should met or exceed the necessary levels. All necessary documentation, such as ICDs, Development and Product Specifications, technical data packs etc must be reviewed prior to the CDR.

The aims of the CDR include:Evaluation of the detailed designDetermine readiness for production/constructionDetermine design compatibilityEstablish the PBL

Successful completion of the CDR results in the PBL. This effectively ends the design phase. (further design activity may arise from discrepancies identified during testing).

3. Explain why integration is the ultimate test of interface identification and design.

Integration aims to combine lower-level components into progressively higher-level sub-systems until the system prototype is complete. Successful integration proves the functional and physical requirements of the interface have been correctly identified and detailed in the Integration Control Documentation (ICD), and the design has treated the interface requirements appropriately to enable the configuration items (CIs) to be successfully mated.

4. How detailed does the Detailed Design and Development effort need to be?

The detailed design effort takes the definitions of the FBL and ABL and starts the to consider the design of the specific subsystem components. THE REALISATION AND DOCUMENTATION OF INDIVIDUAL COMPONENTS IS REFERRED TO AS THE PRODUCT BASELINE.The following tasks are undertaken during DD&D. The major technical ones are:

- Describe the lower level components making up the subsystems.- Defining the characteristics of the above items through specifications and design

data.- Finalising the design of all interfaces necessary to support system integration.- Either procuring the above items off-the-shelf, or designing them if they are

unique to the system under development.- Developing a prototype or engineering model of the final system by integrating the

above items.- Redesigning and retesting aspects of the system prototype that failed to meet the

minimum requirements.- Conducting a critical design review (CDR) to ensure that the design is ready for

construction and production.

5. How can the system engineering process be applied to assist with Construction and/or Production, and describe the possible content of a Production Plan.

a. Systems engineering processes can be used to assist the design and construction engineers to ensure appropriate inputs are available to meet system requirements. These processes include:

(1) Producibility analysis, ie ensure designs can be produced.

(2) Consideration of producibility issues during trade-off studies and selection of preferred design options.

(3) Life-cycle cost considerations accounting for cost of production and construction.

b. The Production Plan should include:

(1) Resources – detail type and size of any plant; and skills, training and qualifications of the workforce required to produce the system.

(2) Production engineering considerations – specify and describe the construction/production schedules, manufacturing methods/techniques, including automation or manufacturing information systems; special tooling and test equipment; and special facilities (storage and handling).

(3) Materials and purchased parts. A complete bill of material, including all COTS and/or modified COTS equipment should be compiled and listed. Long procurement lead time items identified. Specify inventory tracking and/or management system.

(4) Management – outline standard management functions. This should include details of process control, production testing procedures, sub-contractor control, and problem control.

(5) Logistics – detail specific logistics requirements, eg packaging, handling, warehousing, and transportation.

6. Detail the main activities associated with the Utilization Phase of a system’s life cycle.

c. Use of the system.

d. System support, including on-going inspection, maintenance and repair, and monitoring the system’s performance and functionality against its specifications, required performance standards and operational environment – market place, regulatory standards and physical location.

e. Modification of the product, including configuration management to ensure the system remains well documented. Modification ensures the system is contemporary, ie makes best use of available technology, continues to be economical and complies with user / owner and regulatory requirements. Configuration management ensures supportability (eg, training, currency of manuals and procedures etc) and operations.

7. Give some examples of reasons for modifications to the system during the Utilization Phase.

a. Advances in technology, for example:

(1) Improvements to computing power, such as software and/or hardware, enabling enhanced performance.

(2) Improved component (sub-system) designs enabling better performance, reduced power consumption, operation in different environmental conditions etc.

(3) Improved manufacturing techniques enabling use of smaller more efficient components.

b. Component obsolescence may force modification due to unavailability of support.

c. Change in Regulatory requirements, for example:

(1) Amendment to industrial, work health and safety law etc that change operator conditions, requirements for safety features etc.

(2) Change to environmental controls, such as exhaust and noise emissions, restriction on use of asbestos and other hazardous materials, double-hulling of tankers (oilers) IAW international standards etc.

d. Change in operating environment due to market / economic conditions affecting competition and/or opportunity, availability of qualified workforce etc.

e. Operator and/or customer feedback. In Army this would be through the RODUM system.

f. Business analysis by management may identify a requirement for change. For example, cost of inputs (fuel type) may justify converting a power station from coal fired to gas fired.

g. Failure (minor or catastrophic) identified during routine inspection/maintenance or as a consequence of accident investigation.

8. Explain using an example why systems engineering could be applied during a modification exercise.

a. Modification of a component within a system is likely to affect component interfaces (CI), which in turn may effect operation of that system and its outputs.

b. The text uses the example of repowering (fitting a new engine) to an aircraft. An Army example is the modification of the M113 APC. This modification involved

‘stretching’ the vehicle, upgrading the drive-train (repowering, new transmission and running gear), changes to the turret and provision of appliqué armour. The additional weight required upgrade of the vehicle’s brakes. The modification of these significant components affected numerous component interfaces (CI) requiring the relationships and inputs to be reviewed. This review process resulted in changes to technical data packages, training for operators and maintainers, upgrades to tooling and test equipment, changes to processes for transporting the APC (vehicles and loading procedures), changes to inventory holdings and so on.

9. What issues could arise during system phase-out that should have been addressed early in the system life-cycle?

a. Transition from current to new equipment – cost of supporting two fleets, eg training, maintenance, inventory management etc.

b. Delays to introducing new capability and method to cover any potential capability gap; eg either extend current capability or use an interim solution.

c. Changes to operating environment, procedures and governance.

d. Effect on business organisation and workforce, potential need to re-structure, re-train, or re-size.

e. Effect on customers, partnerships etc.

f. Effect on existing contracts both suppliers and customers

10. List and explain three examples of ‘real-world’ disposal problems.

a. The method of disposal could include conversion (eg used for training), sale, gifting, re-cycling, scrapping, dumping. Three real world examples are as follows:

b. Disposal of toxic/hazardous waste, eg radio-active material, asbestos, medical etc.

(1) Moral, Ethical and Statutory obligations.

(2) Need to protect workforce and population within affected area. Eg, during decommissioning of an industrial site containing asbestos.

(3) Requirements to provide on-going support, monitoring etc, particularly for gifted equipment or the disposal of radio-active material.

c. Disposal of weapons and armaments.

(1) Contractual obligations may restrict or constrain methods of disposal; eg Intellectual Property, third party sales due to FMS rules, etc.

(2) Ensure weapons and armaments are not obtained by inimical countries, outlaw groups or terrorist groups.

d. Disposal of commercially classified or sensitive material.

(1) Control of security or sensitive material to maintain competitive advantage.

(2) Cost of preparation for disposal to engage suitably qualified and capable disposal agents.