Difference between revisions of "System Operation"
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024") |
|||
| (96 intermediate revisions by 12 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ---- | |
| − | + | '''''Lead Authors:''''' ''Scott Jackson, Brian Gallagher'', '''''Contributing Author:''''' ''Leopoldo deCardenas'' | |
| − | The role of SE during the operation of | + | ---- |
| + | The role of {{Term|Systems Engineering (glossary)|systems engineering}} (SE) during the operation of a system consists of ensuring that the system maintains key mission and business functions and is operationally effective. The systems engineer is one of the {{Term|Stakeholder (glossary)|stakeholders}} who ensures that maintenance actions and other major changes are performed according to the long-term vision of the system. Both the maintenance actions and any implemented changes must meet the evolving needs of owning and operating stakeholders consistent with the documented and approved architecture. SE considerations will also include the eventual decommissioning or disposal of the system so that the disposal occurs according to disposal/retirement plans. Those plans must account for and be compliant with relevant laws and regulations (for additional information on disposal or retirement, please see the [[Product and Service Life Management]] knowledge area (KA)). When the {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) replaces an existing or legacy system, it may be necessary to manage the migration between systems such that stakeholders do not experience a breakdown in services (INCOSE 2012). | ||
| − | + | ==Definition & Purpose== | |
| − | + | This process assigns personnel to operate the system and monitors the services and operator-system performance. In order to sustain services, it identifies and analyzes operational problems in relation to agreements, stakeholder requirements, and organizational constraints (ISO/IEC/IEEE 2015). | |
| − | This process assigns personnel to operate the system | ||
| − | |||
| − | |||
| − | + | The {{Term|Concept of Operations (ConOps) (glossary)|concept of operations}} (ConOps) establishes the foundation for initial design specifications according to the long-term vision. It is also possible that pre-planned program improvements (P3I) had been generated based on expected evolving requirements. Throughout the {{Term|Life Cycle (glossary)|systems life cycle}}, the operation of the system requires the systems engineer to be an active participant in reviews, change management and integrated master schedule activities to ensure the system operations continue to meet the evolving needs of stakeholders, and are consistent with the architecture through the eventual decommissioning or disposal of the system. In the event of decommissioning, a systems engineer must ensure disposal/retirement plans are compliant with relevant laws and regulations (for additional information on disposal or retirement, see the [[Product and Service Life Management]] KA). | |
| − | + | Two additional areas are of interest to the systems engineer during system operation require special attention. First, it may be determined that a system is at the end of its life cycle, but the cost of replacing the system with a completely new design is too expensive. In this case, there will be intense engineering activities for service life extension program (SLEP). The SLEP solution will take into account obsolescence issues, diminishing manufacturing sources and material shortages (DMSMS), and changes in ConOps. Secondly, in the event that a new SoI is designed and produced as a complete replacement for an existing or legacy system, it will be necessary to manage the migration between systems such that stakeholders do not experience a breakdown in services (INCOSE 2012). | |
| − | |||
| − | |||
| − | *Evaluation | + | ==Process Approaches== |
| + | During the operational phase, SE activities ensure the system maintains certain operational attributes and usefulness throughout its expected life span. Maintaining operational effectiveness consists of evaluating certain operationally relevant attributes and trends, taking actions to prevent degradation of performance, evolving the system to meet changing mission or business needs (see the [[Product and Service Life Management]] KA), and eventually decommissioning the system and disposing of its components. During operation, data would be collected to evaluate the system and determine if changes should be made. It is important to include the process for data collection during operations when considering design and ConOps. In some cases, data may be collected by sensors and reported autonomously. In other cases, operators will identify and report on performance during operations. The systems engineer needs to understand how all data will be collected and presented for further analysis. The systems engineer will be involved in analysis of this data in several areas, including the following: | ||
| + | * Updating training and development of new training as required for operational and support personnel. Training is generally developed early with system design and production and executed during integration and operations. Determination of training updates or changes will be based on evaluation of the operational and support personnel. | ||
| + | * Evaluation of operational effectiveness. Early in the planning phases of a new system or capability, measures of operational effectiveness are established based on mission and business goals. These measures are important during system operation. These attributes are unique for each system and represent characteristics describing the usefulness of the system as defined and agreed to by system stakeholders. Systems engineers monitor and analyze these measurements and recommend actions. | ||
| + | * Failure reporting and corrective actions (FRACA) activities will involve the collection and analysis of data during operations. FRACA data will provide trends involving failures that may require design or component changes. Some failures may also result in safety issues requiring operational modifications until the offending elements under analysis can be corrected. If components or systems must be returned to maintenance facilities for corrective repairs, there will be operational and business impacts due to increased unavailability and unplanned transportation cost. | ||
===Applicable Methods & Tools=== | ===Applicable Methods & Tools=== | ||
| + | Operations manuals generally provide operators the steps and activities required to run the system. | ||
| − | + | ====Training and Certification==== | |
| − | + | Adequate training must be provided for the operators who are required to operate the system. There are many objectives of training: | |
| − | + | * Provide initial training for all operators in order to equip them with the skill and knowledge to operate the system. Ideally, this process will begin prior to system transition and will facilitate delivery of the system. It is important to define the certification standards and required training materials up front (for more information on material supply, please see [[Logistics]]). | |
| − | + | * Provide continuation training to ensure currency of knowledge. | |
| − | + | * Monitor the qualification/certification of the operators to ensure that all personnel operating the system meet the minimum skill requirements and that their currency remains valid. | |
| + | * Monitor and evaluate the job performance to determine the adequacy of the training program. | ||
| + | ==Practical Considerations== | ||
| + | The operation process sustains system services by assigning trained personnel to operate the system, as well as by monitoring operator-system performance and monitoring the system performance. In order to sustain services, the operation process identifies and analyzes operational problems in relation to {{Term|Agreement (glossary)|agreements}}, {{Term|Stakeholder Needs and Requirements (glossary)|stakeholder needs and requirements}}, and organizational {{Term|Constraint (glossary)|constraints}}. When the system replaces an existing system, it may be necessary to manage the migration between systems such that persistent stakeholders do not experience a breakdown in services. | ||
| + | Results of a successful implementation of the operation process include: | ||
| + | * Definition and refinement of an operation strategy along the way | ||
| + | * Delivery of services that meet stakeholder requirements | ||
| + | * Satisfactory completion of approved, corrective action requests | ||
| + | * Continued stakeholder satisfaction | ||
| − | + | Outputs of the operation process include: | |
| − | + | * Operational strategy, including staffing and sustainment of enabling systems and materials | |
| + | * System performance reports (statistics, usage data, and operational cost data) | ||
| + | * System trouble/anomaly reports with recommendations for appropriate action | ||
| + | * Operational availability constraints to influence future design and specification of similar systems or reused system elements | ||
| − | + | Activities of the operation process include: | |
| − | + | * Providing operator training to sustain a pool of operators | |
| − | + | * Tracking system performance and accounting for operational availability | |
| − | + | * Performing operational analysis | |
| − | + | * Managing operational support logistics | |
| − | + | * Documenting system status and actions taken | |
| − | + | * Reporting malfunctions and recommendations for improvement | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
| − | * | ||
==References== | ==References== | ||
| + | ===Works Cited=== | ||
| + | INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2. | ||
| + | ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation (ISO)/International Electrotechnical Commissions (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015. | ||
| + | ===Primary References=== | ||
| + | Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]],'' 5th Edition. Englewood Cliffs, NJ, USA: Prentice Hall. | ||
| − | + | Institute of Engineers Singapore. 2009. ''[[Systems Engineering Body of Knowledge (Singapore)|Systems Engineering Body of Knowledge]]''. Provisional version 2.0. Singapore: Institute of Engineers Singapore. | |
| − | |||
| − | Systems Engineering | + | INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2. |
| − | + | ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation (ISO)/International Electrotechnical Commissions (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015. | |
| − | + | ===Additional References=== | |
| + | None. | ||
| + | ---- | ||
| + | <center>[[System Validation|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Maintenance|Next Article >]]</center> | ||
| − | + | <center>'''SEBoK v. 2.10, released 06 May 2024'''</center> | |
| − | |||
| − | |||
| − | |||
[[Category: Part 3]][[Category:Topic]] | [[Category: Part 3]][[Category:Topic]] | ||
| + | [[Category:System Deployment and Use]] | ||
Latest revision as of 22:25, 2 May 2024
Lead Authors: Scott Jackson, Brian Gallagher, Contributing Author: Leopoldo deCardenas
The role of systems engineering (SE) during the operation of a system consists of ensuring that the system maintains key mission and business functions and is operationally effective. The systems engineer is one of the stakeholders who ensures that maintenance actions and other major changes are performed according to the long-term vision of the system. Both the maintenance actions and any implemented changes must meet the evolving needs of owning and operating stakeholders consistent with the documented and approved architecture. SE considerations will also include the eventual decommissioning or disposal of the system so that the disposal occurs according to disposal/retirement plans. Those plans must account for and be compliant with relevant laws and regulations (for additional information on disposal or retirement, please see the Product and Service Life Management knowledge area (KA)). When the system-of-interest (SoI) replaces an existing or legacy system, it may be necessary to manage the migration between systems such that stakeholders do not experience a breakdown in services (INCOSE 2012).
Definition & Purpose
This process assigns personnel to operate the system and monitors the services and operator-system performance. In order to sustain services, it identifies and analyzes operational problems in relation to agreements, stakeholder requirements, and organizational constraints (ISO/IEC/IEEE 2015).
The concept of operations (ConOps) establishes the foundation for initial design specifications according to the long-term vision. It is also possible that pre-planned program improvements (P3I) had been generated based on expected evolving requirements. Throughout the systems life cycle, the operation of the system requires the systems engineer to be an active participant in reviews, change management and integrated master schedule activities to ensure the system operations continue to meet the evolving needs of stakeholders, and are consistent with the architecture through the eventual decommissioning or disposal of the system. In the event of decommissioning, a systems engineer must ensure disposal/retirement plans are compliant with relevant laws and regulations (for additional information on disposal or retirement, see the Product and Service Life Management KA).
Two additional areas are of interest to the systems engineer during system operation require special attention. First, it may be determined that a system is at the end of its life cycle, but the cost of replacing the system with a completely new design is too expensive. In this case, there will be intense engineering activities for service life extension program (SLEP). The SLEP solution will take into account obsolescence issues, diminishing manufacturing sources and material shortages (DMSMS), and changes in ConOps. Secondly, in the event that a new SoI is designed and produced as a complete replacement for an existing or legacy system, it will be necessary to manage the migration between systems such that stakeholders do not experience a breakdown in services (INCOSE 2012).
Process Approaches
During the operational phase, SE activities ensure the system maintains certain operational attributes and usefulness throughout its expected life span. Maintaining operational effectiveness consists of evaluating certain operationally relevant attributes and trends, taking actions to prevent degradation of performance, evolving the system to meet changing mission or business needs (see the Product and Service Life Management KA), and eventually decommissioning the system and disposing of its components. During operation, data would be collected to evaluate the system and determine if changes should be made. It is important to include the process for data collection during operations when considering design and ConOps. In some cases, data may be collected by sensors and reported autonomously. In other cases, operators will identify and report on performance during operations. The systems engineer needs to understand how all data will be collected and presented for further analysis. The systems engineer will be involved in analysis of this data in several areas, including the following:
- Updating training and development of new training as required for operational and support personnel. Training is generally developed early with system design and production and executed during integration and operations. Determination of training updates or changes will be based on evaluation of the operational and support personnel.
- Evaluation of operational effectiveness. Early in the planning phases of a new system or capability, measures of operational effectiveness are established based on mission and business goals. These measures are important during system operation. These attributes are unique for each system and represent characteristics describing the usefulness of the system as defined and agreed to by system stakeholders. Systems engineers monitor and analyze these measurements and recommend actions.
- Failure reporting and corrective actions (FRACA) activities will involve the collection and analysis of data during operations. FRACA data will provide trends involving failures that may require design or component changes. Some failures may also result in safety issues requiring operational modifications until the offending elements under analysis can be corrected. If components or systems must be returned to maintenance facilities for corrective repairs, there will be operational and business impacts due to increased unavailability and unplanned transportation cost.
Applicable Methods & Tools
Operations manuals generally provide operators the steps and activities required to run the system.
Training and Certification
Adequate training must be provided for the operators who are required to operate the system. There are many objectives of training:
- Provide initial training for all operators in order to equip them with the skill and knowledge to operate the system. Ideally, this process will begin prior to system transition and will facilitate delivery of the system. It is important to define the certification standards and required training materials up front (for more information on material supply, please see Logistics).
- Provide continuation training to ensure currency of knowledge.
- Monitor the qualification/certification of the operators to ensure that all personnel operating the system meet the minimum skill requirements and that their currency remains valid.
- Monitor and evaluate the job performance to determine the adequacy of the training program.
Practical Considerations
The operation process sustains system services by assigning trained personnel to operate the system, as well as by monitoring operator-system performance and monitoring the system performance. In order to sustain services, the operation process identifies and analyzes operational problems in relation to agreements, stakeholder needs and requirements, and organizational constraints. When the system replaces an existing system, it may be necessary to manage the migration between systems such that persistent stakeholders do not experience a breakdown in services.
Results of a successful implementation of the operation process include:
- Definition and refinement of an operation strategy along the way
- Delivery of services that meet stakeholder requirements
- Satisfactory completion of approved, corrective action requests
- Continued stakeholder satisfaction
Outputs of the operation process include:
- Operational strategy, including staffing and sustainment of enabling systems and materials
- System performance reports (statistics, usage data, and operational cost data)
- System trouble/anomaly reports with recommendations for appropriate action
- Operational availability constraints to influence future design and specification of similar systems or reused system elements
Activities of the operation process include:
- Providing operator training to sustain a pool of operators
- Tracking system performance and accounting for operational availability
- Performing operational analysis
- Managing operational support logistics
- Documenting system status and actions taken
- Reporting malfunctions and recommendations for improvement
References
Works Cited
INCOSE. 2012. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation (ISO)/International Electrotechnical Commissions (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015.
Primary References
Blanchard, B.S. and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5th Edition. Englewood Cliffs, NJ, USA: Prentice Hall.
Institute of Engineers Singapore. 2009. Systems Engineering Body of Knowledge. Provisional version 2.0. Singapore: Institute of Engineers Singapore.
INCOSE. 2012. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation (ISO)/International Electrotechnical Commissions (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15288:2015.
Additional References
None.