Home » SyEN Newsjournal » PPI SyEN 43

PPI SyEN 43

Read monthly Project Performance International's Systems Engineering Newsjournal, named "PPI SyEN". PPI SyEN presents for the engineering professional 30-60 pages of valuable technical articles on topical subjects, shorter technical pieces, in-depth coverage of the month's news in systems engineering and directly related fields, pointers to useful resources and relevant industry events, plus limited information on PPI's activities.

Welcome to PPI SyEN 43

WHAT’S INSIDE:

Quotations to Open On

Read More…(link/anchor to PPI Events)

Editor’s Note: Quotation in SyEN 41 now has an author!

In the February 2012 edition of SyEN we included the quotation: “To the optimist, the glass is half full. To the pessimist, the glass is half-empty. To the systems engineer, the glass is twice as big as it needs to be” – Unknown. We are pleased to announce that the author has been found, and is Mr. Paul Davies. Paul is Head of Innovations Group, Defense Mission Systems, of Thales, UK.

Editors Note: SyEN 42: System(s) of Systems, System(s) of Systems Engineering (SoSE)

In the March 2012 edition of SyEN, a definition of System of Systems was attributed to Sage and Cuppan (2001), and the reference does include the definition. The origin of the definition is Maier, Mark W. 1998, “Architecting Principles for System-of-systems.” Systems Engineering 1 (4): 267–284. Thanks to Dr. Clifton Baldwin for pointing this out.

Quotations to Open On

“As quality increases, productivity increases. This fact is well known

but only to a select few.”

– W. Edwards Deming

“Yes, maybe I have a clear writing style, but actually I have first to

understand for myself what I’m writing.”

– BG Massimo Pica

Feature Article

AN AFFORDABLE SYSTEMS VERIFICATION ACTIVITY

Jeffrey O. Grady

Owner JOG System Engineering

6015 Charae Street

San Diego, CA 92122

jeff@jogse.com

Introduction

Verification is a process for developing evidence that the design solution satisfies the requirements on which it is based. The purpose of verification is to determine the degree of compliance between the design of the system and its lower tier entities and the content of the specifications corresponding to those entities. The verification work must be preceded by an effective requirements activity that results in a set of specifications containing in each case a minimum but complete collection of well-formed requirements statements derived from a modeling approach applied on all programs. The typical methods used to verify compliance include test, analysis, demonstration, and inspection. Verification techniques include walkthroughs, performance testing, simulation, database analysis, algorithm analysis, functional testing, stress testing, and interface testing. The outputs of the verification work are documented verified requirements; an updated requirements traceability matrix; and updated preliminary operational and system concept documents. Addressing requirements verification early, during requirements development, provides opportunities to control cost and risk. Obviously, the verification approach impacts the cost and effort required for verification. Use of a verification planning checklist facilitates asking the right questions. Performing the steps described in this paper will result in an affordable systems verification activity.

Verification Purpose

The purpose of the verification work is to determine the degree of compliance between the design of the system and its lower tier entities and the content of the specifications corresponding to those entities. The content of the specifications is intended to be the basis for the design of the system in that they each specification contains the essential characteristics that the system and its entities must possess. Therefore, the specification becomes the standard against which the product is compared in verification activity.

Verification Process

Entry into the verification activity for a particular system entity (system, subordinate product entity, or interface entity) coordinates with the requirements database containing verification requirements for all product requirements in sections 3 and 5 of the specification for that entity coordinated with methods of verification (test, demonstration, analysis, or examination) assigned. This transition from requirements into verification activity need not be delayed until completion of all requirements analysis activity. Rather, it should be started as each specification is completed beginning with the system specification so the verification design activity should be in progress throughout the requirements analysis activity progressively expanding as the lower tier layers of the work continue. Figure 1 illustrates how this activity should flow as described in subordinate paragraphs.

Figure 1 Systems Verification Activity

Figure 1 shows three major portions of the verification work and an overall management activity all of which will be explained. There are two views of the activity of interest as suggested by the horizontal and vertical orientations of the diagram. The activity takes place in three major sequential steps (illustrated in the vertical columns on the diagram): (1) plan the verification activity, (2) accomplish the activity in accordance with that plan, and (3) report the results to the customer and/or submit to an audit of the evidence of compliance. The three phase related channels are identified as activities beginning with modeling ID strings beginning with F2# so that each of the three need only be discussed once in this overview. Primary inputs to this activity are three kinds of specification: (1) one system specification, (2) multiple item performance specifications, and (3) multiple item detail specifications. We will explore these kinds of specifications shortly and their purpose.

The overview of this activity will be explained from this perspective because all three major sequences are performed in essentially the same way and can all be described in a single discussion. Of course, there are unique distinctions in each of the three sequences that paper size will not permit coverage of. The description of the verification activity in this paper has been overwhelmingly influenced by the author’s many years of experience in the development of systems primarily for military purposes. As a result, the Department of Defense way of organizing systems and the work to develop them is apparent. However, this approach was evolved from many years of procurement experience of some very complex systems to satisfy very difficult needs and the same basic process can serve very well the needs of the developer of commercial systems whether the products be complex or not.

In addition to the major sequence focus, the activity is commonly partitioned into three major phases each coordinated with a kind of specification (the three horizontal rows in the diagram). A development program will have only a single system specification so that row only shows a single flow. A system will consist of two or more product entities that interact through interface entities. The latter may be covered by interface specifications or the requirements for these may be included in pairs (recognizing the two terminals of each interface) of product entity specifications under interface requirements. Thus at the item level under the system we will have to deal with multiple specifications of two kinds. In Figure 1 only three are shown but in most systems there will be quite a few reflecting an expanding hierarchy of product entities. A generic activity designator “&” is used as a vehicle of discussion to avoid discussing each of the three major steps in the verification activity for each phase.

Specifications

In Figure 1 the reader will note that the three major inputs to the verification activity are three kinds of specifications. Commonly, the item qualification work is accomplished first based on the content of the item performance specifications that are intended to be the basis for the development of the item design. Following completion of item qualification, system test and evaluation is authorized because all of the entities that the end items of the system shall be assembled from will have proven that they comply with their specification content. The content of the system test is the basis for the development test and evaluation (DT&E) activity accomplished by the developer of the system. After the system has completed DT&E activity successfully and sufficient system assets have been delivered to the user, the user will commonly conduct an operational test and evaluation (OT&E) to gain confidence that the system is adequate to perform the missions the user must be capable of performing. As production begins every product entity produced must be subjected to an acceptance verification based on the content of the item detail specification content.

The flow of verification activity in Figure 1 must actually be combined with the flow of product to fully grasp the complexity of the verification process. Item qualification is normally accomplished using product entities manufactured in an engineering shop, for there is not normally a production line available at the time that these entities must be made available. The production line that produces the end items needed for DT&E may be referred to as a low rate production line, and once the DT&E has been completed and results approved by the customer a full rate production line may be ready to begin producing production units that will flow to the field to provide material needed for OT&E and start providing for deliveries to those who will use the system.

Formal acceptance is not always required for the items produced for item qualification and may not be required for product produced to support DT&E. But, a contractor is wise to employ a draft acceptance verification plan and procedure as early in a program as possible so that it will be a fully proven process by the time it must be formally applied. This practice is also supportive of the developer’s claim that the products manufactured on a production line will perform the same way that those proven to comply with specification content that were manufactured in small numbers in an engineering laboratory by engineers and highly skilled mechanical and electrical technicians.

It should be noted that both the system and lower tier item performance specifications are performance specifications intended to convey to the design community the essential characteristics that the design must possess. They are specifications for the design of the product. The item detail specifications are the basis for the design of the acceptance process through which the developer will make decisions on the suitability of every product article completing the manufacturing process for delivery to the customer. Systems are commonly manufactured and delivered in terms of the end item product entities that compose them so there is no need for a system detail specification.

Verification Documentation

In the past, paper documents were prepared using typewriters and later computer word processors for three sets of verification documents: plans telling what was to be done for a particular task, procedures telling the precise order in which task work was to be done with pass-fail criteria clearly defined, and reports giving the results of the task relative to the question of the degree to which it was established through performing the task that the product design was shown to be compliant with the requirements the task was responsible for. Computer applications are available today for capturing the requirements derived from modeling into requirements databases that can be extended to include capture of all verification documentation with clear traceability from entity requirements through verification requirements, the assigned methods, allocation to specific tasks under the responsibility of a particular principal engineer, the content of the plans, procedures, and reports related to the tasks. In this case the option is available to publish plans, procedures, and reports in paper as we did in years past or deliver to the customer the verification data in computer media.

I have long preferred the development of a set of integrated verification plan, procedure, and report documents with one of each for each entity where verification is necessary. In this configuration, one of each of these three documents is prepared for each entity requiring considerable organization and management skill because they will each draw content from many tasks of all four methods and therefore many principal engineers. The advantage is that it collects all of the documentation needed for an audit in one document however it is published.

The alternative is to prepare a collection of plans, procedures, and reports each for one specific task of one particular method. In this case the principal engineer for the task is entirely responsible for the three documents corresponding to his or her task and the process can be more easily managed toward a satisfactory conclusion as far as that principal engineer is concerned.

Depending on how the requirements are allocated to verification tasks, some task documentation may be very thin consisting of a cover page, a table of contents, and a couple of pages of text. This is particularly true for non-test methods. In other cases the documentation may be fairly voluminous, especially if integrated verification documentation is employed. In this overview of verification work, the documentation method covered employs the individual task focus because of the degree of difficulty in explaining and managing the integrated approach.

Major Verification Activities

This discussion covers the verification activity in terms of a generic portrayal applying to all three horizontal frameworks on Figure 1. In this paper we will only discuss item qualification but these phases have much in common in each of the three sequence steps of planning, accomplishing, and reporting the results.

The discussion focuses on one particular product entity at whatever level we choose. The level of choice for DoD programs is commonly the configuration item. For each of these items on a development contract there is a series of major reviews and audits where the customer formally reviews contractor progress and makes formal decisions in each case about contractor performance relative to contractual obligations. Early in the development effort system requirements and system design reviews are held, but subsequent reviews and audits are commonly held at the configuration item level. These remaining ones are: (1) preliminary design review (PDR) where the customer reviews configuration item design concepts; (2) critical design review (CDR) where the customer reviews the completed design of a configuration item; (3) functional configuration audit (FCA) where the customer audits the qualification verification evidence for a configuration item; and (4) physical configuration audit (PCA) where the customer audits the configuration item first production article acceptance verification evidence. The FCA appears in activity F2#3213 of Figure 1for each configuration item and PCA appears in activity F2#3313 of Figure 2.

Verification Planning

The planning activity consists of three basic steps pictured in Figure 2. All of the activity pictured is taking place within activity F2#3X1 shown on Figure 1 and is intended to portray the planning work required for the first step in any of the three phases corresponding to system, item performance, or item detail specifications. This work is required for every system entity for which a specification is developed on a program. The input to this activity is a specification in paper, computer image of the specification, or in database form. The output is a set of plans and procedures, a pair for each entity to be verified as compliant with its requirements.

Figure 2 Plan Verification Activities

For any given system entity, all of the requirements (generally limited to Sections 3 and 5 of the specification template encouraged by the author and DoD) in the entity specification, each of which was assigned to it a method of verification in the development of the specification, must be assigned to a specific task. One way to do this would be to assign every requirement in each specification to a single unique task. This is not the most cost-effective way of designing the program verification plan. However, to do this critically important activity we must assign a task principal to each task who will be responsible for developing the task plan and procedure, accomplishing the task in accordance with the plan and procedure, and reporting upon the task. All of the tasks are linked in a verification schedule and coordinated with a budget. These first three tasks in activity F2#3&11 of Figure 2 are accomplished across all program tasks.

As is apparent from Figure 2, something different happens from this point forward in the planning activity. The work splits into many task-oriented activities all of which come back together with the completion of task reports. The program organizational entity, generally a systems engineering element, responsible for the overall verification activity, should develop and deliver a copy of a list of the requirements that each task principal is responsible for developing evidence of compliance based on task results. The assigned task principals must subsequently accomplish their work for each entity related verification task with the result being that each task has a published, reviewed, and approved plan and procedure under configuration control. The plans must not become approved unless they include the list of requirements assigned to the task coordinated in a table with references in the report to the location of the evidence of compliance. This is the key to affordable verification.

In this paper the author has chosen to refer to the work that must be accomplished on a program as activities in preference to functions because of his conversion from years of support for functional analysis as his preferred modeling approach to UML-SysML where what are called functions in functional analysis are referred to as activities in UML-SysML. However, from years of habit the author could not bring himself to refer to the activity diagram block by anything but functions in terms of their assigned numbering.

Design Verification Process for an Entity

In some way, the person or persons responsible for designing the verification activity, commonly a system engineering responsibility, must organize all of the requirements in all of the specification Sections 3 and 5 into a collection of verification tasks in task F2#3&111 of Figure 2. This must be done for each of the three verification phases (system, item qualification, and item acceptance) but these three phases can be discussed generically because they are essentially the same. As noted earlier, there are four generally accepted methods of verification (test, analysis, demonstration, and examination) to which we may add “none”. So, the first problem is to partition all requirements by method. In each specification there should be a verification traceability table linking each requirement in Sections 3 and 5 with one or more corresponding requirements in Section 4. The Section 3 requirements provide the design engineer with the essential characteristics of the entity they must complete a design for. Section 4 tells the requirements for the verification task where it will be determined to what extent the entity design complies with the entity requirements. Further this table should define the method to be used in that verification task.

The “None” method subset is composed of all of those specification paragraphs consisting of only a paragraph number and title with no accompanying sentences or containing sentences that fail to define essential characteristics that the design must possess. In the author’s specification template, Paragraph 3.1 and all of the content of its sub-paragraphs would also be excluded, since it deals with introductory information and reference to the modeling approach employed through which the remaining content of Section 3 was derived. The content of Paragraph 3.2 dealing with performance, Paragraph 3.3 dealing with interfaces, Paragraph 3.4 dealing with specialty engineering, and Paragraph 3.5 dealing with environmental requirements containing shall statements would be included in the set of requirements that must be verified. Each of these will have a method prescribed in the verification traceability table in the specification.

The challenge for the person or persons responsible for designing the verification work is to collect the requirements into groups with the same method that are related in some way such that they can all be verified applying a common approach, equipment, technique, and/or personnel.

Commonly, it works out best if all of the requirements in a specification are verified in a set of tasks that are focused on the content of that specification. Cases may arise where it is possible to best achieve the desired outcome from the overall verification activity by covering the content of parts of multiple specifications in single tasks that bridge the boundaries of single specifications. For example the author has seen all of the reliability, availability, and maintainability verification work for the whole system and all of its parts bundled into a single task and report. Similarly, a system mass properties task can be organized so that it is reported at the system level where everything is weighed and reported upon in a single report. While organizing tasks relative to product entities is a good norm, to deny the team access to promotion or demotion of requirements across entity boundaries does run the risk of increasing verification cost.

As each task is identified and a principal engineer named, that engineer should be provided with a list of requirements they must provide compliance data for in a task report containing the table showing how those requirements map to the content of the report. This simple move of providing each task principal with a list of requirements and requiring that that principal’s report trace the requirements to report content will pay dividends as the verification work is completed and is audited by the customer.

Prepare Task Plan

The principal task engineer begins the process of preparing a task plan by making a copy of the enterprise Verification Task Plan template for the method to be applied and identifying it relative to the entity and task assigned. The tasks can be assigned at any level in the system from system level to the lowest entity where verification is required on the program. The principal will have received a table from system engineering identifying the requirements that correspond to the task involved and must place this table in the plan coordinated, as the plan content matures, with the paragraphs, figures, and tables where task activity produces insight into the degree of proven product compliance with listed requirements.

It is critically important that the plan include the verification table given to the principal engineer that lists all of the requirements for which the task must produce evidence of compliance. The reason for this is that principal engineers tend not to focus adequately on establishing a clear traceability path between the requirements and the evidence of compliance included in the report, leading to a considerable waste of time on the part of the system engineers who must make these connections. Where some time passes between the completion of a report and efforts to submit evidence of compliance to the customer, it will be more difficult to make these connections because the principal engineer may have been reassigned to another program and not be available to assist.

Once a plan has been completed it should be reviewed and approved or rejected for correction by the principal engineer. Once approved, the plan should be placed under configuration control such that the master may not be altered without review and approval.

Prepare Task Procedure

As soon as the plan is approved the principal can begin preparation of the task procedure that contains step-by-step instructions for accomplishing the task. In some cases this may be as simple as a single sentence such as “Place item on a calibrated scale and read scale.” In other cases, especially involving tests, the procedure may be very involved requiring multiple people to accomplish steps coordinated with responses from prior steps and dynamic performance of the product under test.

The completed procedure must be reviewed and approved followed by placement under configuration management control. The review must include coordination with the plan such that it is clear that the procedure and plan are mutually consistent. Changes to the procedure, like the plan, must be reviewed and approved and placed under configuration item control before the procedure is employed to control work on a verification task.

Task Accomplishment and Reporting

Figure 3 shows an activity diagram for accomplishing the planned task and reporting upon the results. As the time for implementation of the verification task approaches on the schedule, the task principal engineer must ensure that resources planned for availability in support of the task will be available and in good condition. This may include training some task personnel if test or demonstration is the method of verification.

As the task is accomplished, a record of results is kept with particular attention to pass-fail criteria for each step and the map of task results relative to requirements, so as to ensure that the report covers compliance evidence. The map is passed to system engineering and results are entered in the VCRM data by system engineering.

The principal engineer prepares the task report including the map and passes it on for review and approval. The approved plan is placed under configuration management control. Part of the review and approval process is for a system engineer involved in the verification work who checks the evidence in the report that is referenced in the map to see if the evidence is convincing.

Upon completion of any verification task the principal engineer has a responsibility to prepare a report of findings. This report should include the table provided to the principal engineer with report references to the evidence contained in the report for each requirement mapped to that task.

Program Verification Reporting and Auditing

In addition to the reporting that principal engineers do regarding the task they are responsible for, the customer must be kept informed about the progress of the verification work and in the end for each of the phases (item qualification, system, and item acceptance) the customer may require the contractor to provide them with an audit of the verification evidence. So, we will break this discussion down into those three parts after a few words about in-process reporting.

Figure 3 Accomplish Verification Task

Verification Management

Requirements verification work seeks to provide clear evidence of the degree of compliance between the requirements for a system entity and the degree of entity compliance with those requirements. All verification work deals with comparisons between an entity of interest and a standard of excellence in the form of the requirements that were intended to supply the design engineer the minimum essential characteristics for the design. This comparison must be accomplished with full attention focused on the truth, avoiding any temptations to shade the results untruthfully in the favor of cost or schedule limitations. Those limitations will become a real problem only to the degree that verification design was accomplished badly or not at all.

Activity A2#35 shown on Figure 1 is a continuation of this same activity from the systems requirements work earlier in a program and should provide programs with a single requirements and verification tool set so as to provide for maximum integrity of the data. This set should embrace all of the requirements for system, hardware, and software. This common repository would ideally provide for the hierarchical and modeling traceability, VCRM record keeping, publishing specifications, ad hoc access, and management support. In the most expansive form this tool set would also provide for verification plans, procedures, and reports as well with all of the inter-document traceability discussed elsewhere in this paper.

Conclusion

Developing a set of integrated verification plan, procedure, and report documents for each entity where verification is necessary has in my experience provided the best approach. Major verification activities include verification planning, designing a verification process for each entity, preparing the task plan, preparing the task procedure, task accomplishment and reporting, program verification reporting and auditing, and verification management. Performing these steps will result in an affordable systems verification activity.

Systems Engineering News

Requirements Engineering and Business Analysis:

State of Practice Study

Dr. Samuel A. Fricker, Blekinge Institute of Technology, http://www.bth.se/com/sfr.nsf/pages/samuelafricker, is conducting a scientific survey to understand the current state of art in requirements engineering / business analysis and how it has evolved. The landing page after the survey gives an initial overview of the responses to the survey, and hence allows comparison with others. Detailed analysis follows the conclusion of data collection.

More information and the survey (embed hyperlink) http://bit.ly/re-practice

Fujitsu Establishes New Regional Systems Engineering Companies

Launch of Fujitsu Systems East and Fujitsu Systems West Marks Reorganization and Integration of Fujitsu’s Regional Systems Engineering Companies.

Fujitsu has announced the reorganization of its regional systems engineering (SE) companies – four companies in eastern Japan and six companies in western Japan – with the two new organizations to be known as Fujitsu Systems East Limited and Fujitsu Systems West Limited, respectively. As regional SE operations for the Fujitsu Group, the two newly integrated companies, together with Fujitsu Kyushu Systems Limited, which was formed in April 2009, will be the backbone of Fujitsu’s solutions and systems integration business.

More Information (embed hyperlink)

http://www.marketwatch.com/story/fujitsu-establishes-new-regional-se-companies-2012-03-21

SysML Versions 1.3 and 1.4

Version 1.3 of the systems engineering modeling language SysML will be published in a few weeks time. Development of a version 1.4 is underway. The full scope of changes incorporated in version 1.3 is not publicly available. Most changes appear to be in the area of ports. The goals for version 1.4, similarly, are not publicly available.

A full report on SysML 1.3 will be published in SyEN once this version of the language is released.

INCOSE Brasil Chapter Formed

The Brazil INCOSE Chapter and its Board of Directors was established on 26th March, 2012, at a meeting of INCOSE members in São José dos Campos, SP, Brasil. The necessary bureaucratic process to create a formally legalized entity under Brazilian Law has now commenced, with an expectation of completion by July 2012. Professor Geilson Loureiro and Dr. George Sousa are respectively President and Vice-President elect.

Vitech Corporation and INCOSE Announce 2012 Fellowship

Award Application Process is Now Open

Vitech Corporation has announced that the application process is now open for the James E. Long Memorial Post-Doctoral Fellowship Award, established by the International Council on Systems Engineering (INCOSE) Foundation. Honoring and recognizing the many contributions to the field of systems engineering by Jim Long, Vitech’s former CEO, the yearly fellowship will be awarded at the 22nd annual INCOSE International Symposium in Rome, July 9-12, where nearly 1,000 of the world’s leading systems engineers will gather. The $5,000 award supports post-doctoral research with the potential to advance the state of the art in systems thinking or the systems perspective, or advance the practice of systems engineering.

More information http://www.mfrtech.com/articles/25888.html

Ask Robert

Question: Is the objective of systems engineering to reduce risk?

Answer: An objective of systems engineering to reduce risk. The objective of systems engineering is to maximize value delivery to the applicable (primary) stakeholders.

Question: Is it useful to regard a project plan as a system?

Answer: While technically a project plan is a system, no, it is not useful to view a project plan as a system.

What is enormously valuable is to view a project plan as a description of a system, specifically a description (design) of a project system. When that view is taken, it suggests that systems engineering principles and practice can, and should, be applied to project planning (and re-planning). An examination of historical project failures and the associated reasons, on which there is a plethora of data, support the conclusion.

The project manager, in the role of planner, can and should be regarded as the systems engineer of the project system.

Robert Halligan, FIE Aust

Featured Society

International Federation of Automatic Control

The International Federation of Automatic Control (IFAC), founded in 1957, is a multinational federation of National Member Organizations (NMOs), each one representing the engineering and scientific societies of its own country which are concerned with automatic control. The aims of the IFAC are to promote the science and technology of control in the broadest sense and in all systems, whether, for example, engineering, physical, biological, social or economic, in both theory and application. IFAC is also concerned with the impact of control technology on society.

IFAC pursues its purpose by organizing technical meetings, by publications, and by any other means consistent with its constitution and which will enhance the interchange and circulation of information on automatic control activities. International World Congresses are held every three years. Between congresses, IFAC sponsors many symposia, conferences and workshops covering aspects of automatic control.

The technical areas covered by IFAC are addressed by IFAC’s Technical Committees. These Committees are responsible for the planning and monitoring of the technical events, such as symposia, conferences and workshops, with the NMOs acting as hosts. The technical areas are also promoted by the Technical Committees in other ways, such as establishing contacts with other international organizations, and publication of reports on selected topics.

The current Technical Committees are:

CC 1 – Systems and Signals

TC 1.1. Modeling, Identification and Signal Processing

TC 1.2. Adaptive and Learning Systems

TC 1.3. Discrete Event and Hybrid Systems

TC 1.4. Stochastic Systems

TC 1.5. Networked Systems

CC 2 – Design Methods

TC 2.1. Control Design

TC 2.2. Linear Control Systems

TC 2.3. Non-Linear Control Systems

TC 2.4. Optimal Control

TC 2.5. Robust Control

TC 2.6. Distributed Parameter Systems

CC 3 – Computers, Cognition and Communication

TC 3.1. Computers for Control

TC 3.2. Computational Intelligence in Control

TC 3.3. Telematics: Control via Communication Networks

CC 4 – Mechatronics, Robotics and Components

TC 4.1. Components and Technologies for Control

TC 4.2. Mechatronic Systems

TC 4.3. Robotics

TC 4.5. Human Machine Systems

CC 5 – Manufacturing and Logistics Systems

TC 5.1. Manufacturing Plant Control

TC 5.2. Manufacturing Modeling for Management and Control

TC 5.3. Enterprise Integration and Networking

TC 5.4. Large Scale Complex Systems

CC 6 – Process and Power Systems

TC 6.1. Chemical Process Control

TC 6.2. Mining, Mineral and Metal Processing

TC 6.3. Power and Energy Systems

TC 6.4. Fault Detection, Supervision & Safety of Technical Processes

CC 7 – Transportation and Vehicle Systems

TC 7.1. Automotive Control

TC 7.2. Marine Systems

TC 7.3. Aerospace

TC 7.4. Transportation Systems

TC 7.5. Intelligent Autonomous Vehicles

CC 8 – Bio- and Ecological Systems

TC 8.1. Control in Agriculture

TC 8.2. Biological and Medical Systems

TC 8.3. Modeling and Control of Environmental Systems

TC 8.4. Biosystems and Bioprocesses

CC 9 – Social Systems

TC 9.1. Economic and Business Systems

TC 9.2. Social Impact of Automation

TC 9.3. Developing Countries

TC 9.4. Control Education

TC 9.5. Supplemental Ways of Improving International Stability

IFAC activities are for everyone interested in control engineering research, development and education. About fifty National Member Organizations are involved in promoting and developing the area of control by organizing technical meetings and by publishing control literature – including Preprints and Proceedings of IFAC meetings, the IFAC Journals Automatica, Control Engineering Practice, Annuals Review in Control, Journal of Process Control and Engineering Applications of Artificial Intelligence, and a number of affiliated journals.

More information: http://www.ifac-control.org/

INCOSE Technical Operations

Motor Sports Working Group

Charter

Leverage the excitement and enthusiasm inherent in motor sports to accelerate learning about systemics, science, technology, engineering and mathematics and other subjects.

Leadership

Chair: Jack Ring

Co-chair: Bill Mackey

Contact jack.ring@incose.org for additional information or to join this group.

Planned Work

Evolve an SE in Motor Sports 101 syllabus

Compile multimedia for use in classrooms

Devise a series of modeling exercises

Work with schools and sponsors to encourage adoption of the motor sports advantage

Published Products

MSWG Charter

MSWG Backgrounder

Draft syllabus “What Does It Take to Get to the Checkered Flag?”

Presentations and Links

2008 International Workshop Motor Sports WG Summary Presentation Size: 200K

http://agelesslearner.com/articles/learningbydoing_jring_tc600.html

http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/rt/printerFriendly/727/636

http://www.nsf.gov/news/special_reports/sos/?WT.mc_id=USNSF_51

Systems Engineering Tools News

Addition to Requirements Management Tools List

SpecWave http://www.teecspecs.com/products.cshtml A specification modeling system

tracecloud http://www.tracecloud.com/GloreeJava2/jsp/WebSite/TCHome.jsp A RM tool

RequirementOne http://www.requirementone.com/Project-Management-Platform A web-based RM service.

TEEC® Releases SpecWave® – A Specification Modeling System for Engineering Projects

TEEC, The Engineering Essentials Company, has announced the release of SpecWave® 2012, a specification modeling system. TEEC, and its SpecWave technology aim to help architectural and engineering firms speed and improve:

Master specification clean-up and ongoing management,

Project specification production

Multi-purpose publishing to specification end-users

Change management to specifications in the field, and

Update and re-use of lessons learned and field improvements into master specifications.

More Information (embed hyperlink)

http://www.teecspecs.com/products.cshtml

Visure Solutions Announces Test Management Extension for IRQA

Visure Solutions has integrated test management into its IRQA requirements engineering solution. With this addition to IRQA, developers of safety- and mission-critical software can automate end-to-end requirements traceability, with fulfilled tests providing the evidence points needed for regulatory certification.

More Information (embed hyperlink)

http://eon.businesswire.com/news/eon/20120227005580/en/Visure-Solutions/IRQA/requirements-management

LDRA Integrates Requirements Engineering Tool into LDRA Tool Suite

LDRA has announced the integration of Visure Solutions’ IRQA requirements engineering tools with TBmanager, a test management and traceability component within the LDRA tool suite. This integration eases regulatory compliance by providing transparent, end-to-end traceability from system requirements to verification and validation for safety- and mission-critical software. Process-oriented standards, such as DO-178C and ISO 26262, mandate that all source code and validation tests be traceable to requirements. This mandate ensures that the embedded software fulfills all requirements, operates correctly, and has no extraneous code not associated with a requirement.

More Information (embed hyperlink)

http://www.techonlineindia.com/article/12-03-26/LDRA_integrates_requirements_engineering_tool_into_LDRA_tool_suite.aspx

Control Model-Based Systems Engineering with SysML Design Quality Metrics

The release of SDMetrics V2.3, a software design quality measurement tool for the Unified Modeling Language (UML), was announced in late March 2012. SDMetrics measures structural design properties such as coupling, size, and complexity of UML designs. SDMetrics also checks design rules to automatically detect incomplete or incorrect design, and adherence to style guidelines such as circular dependencies or naming conventions. Software developers use this information to focus their design reviews, design refactoring, and testing efforts on the potentially critical areas that are likely sources of reliability or maintainability problems in their software designs. SDMetrics V2.3 adds support for analyzing UML models that are extended by UML profiles. A prominent example of a UML profile is the Systems Modeling Language (SysML). The SysML adds common concepts from model-based systems engineering (MBSE) to the UML. SDMetrics users can define custom design metrics and rules to take these extensions into account. The support for UML profiles such as SysML extends the scope of SDMetrics V2.3 beyond software system design. Systems engineers need model-based metrics to manage large-scale projects. SysML metrics are an important input to design and development effort estimation, and monitoring of design and development progress. SysML design rules assess the completeness, correctness, and consistency of SysML models. SDMetrics V2.3 provides systems engineers with SysML metrics and rules that are custom-tailored to their local MBSE processes.

More Information (embed hyperlink)

http://www.pr.com/press-release/401601

TOPCASED 5.1.0 Now Available

TOPCASED 5.1.0, an open-source toolkit for critical systems, is now available. The new release is based on the latest Eclipse 3.7.1 platform (Indigo).

Critical Systems Topcased is a software environment primarily focused on the realization of critical embedded systems which include hardware and/or software. Modeling Topcased promotes model-driven engineering and formal methods as key technologies.

Open-source Topcased is released as free open-source software by a group of partner organizations which include Airbus France, EADS Astrium, Rockwell Collins, and Thales.

More Information (embed hyperlink) http://www.topcased.org

Open source MBSE Plugin for MagicDraw with SysML

The INCOSE Telescope modeling challenge team has released version 1.1. of its MBSE plugin for MagicDraw with SysML:

The Plugin for the MagicDraw modeling tool provides support for model based document generation which ties together system model and documents to keep them up to date and consistent, using a AWYSIWYG editor in MagicDraw.

The plugin provides basic support to model variants and extract variants from a system model. It also provides support to generate organizational structures. The plugin provides basic pattern based support to reason on a system model, for example to extract numbers like total power, cost, power consumption for a given product tree

The MBSE plugin for MagicDraw requires MagicDraw 17.0 SP4 or higher with an installed SysML plugin 17.0 SP5 or higher.

More Information (embed hyperlink) https://sourceforge.net/projects/mbse4md/

Systems Engineering Books, Reports, Articles and Papers

Engineering Mega-Systems: The Challenge of Systems Engineering in the Information Age

Renee Stevens

Published by: Auerbach Publications

ISBN: 9781420076660

Publication Date: July 15, 2010

Abstract: With their ability to cross traditional boundaries and achieve a level of functionality greater than their component elements, mega-systems have helped corporations and government organizations around the world resolve complex challenges that they otherwise couldn’t address with stand-alone systems. This book provides a clear understanding of the engineering of this class of systems—a process that demands consideration of increasing program scale and the rapid change of underlying technologies. The author is a Senior Principal Engineer at The MITRE Corporation with decades of experience analyzing, engineering, and acquiring large-scale systems for the U.S. Department of Defense and other government agencies. The book explains how the engineering of mega-systems is inherently different from that of large-scale monolithic systems. It supplies the vocabulary and framework needed to explore the issues relevant to mega-systems. This framework then evolves into the Profiler diagnostic tool that helps you understand the nature and context of the system at hand and, on that basis, select the most appropriate processes, tools, and techniques. Stevens examines commercial and government applications of mega-systems to provide insight into the contemporary challenges of engineering these systems in three critical dimensions: engineering processes, management processes, and the larger context in which these systems are developed and deployed. Complete with two case studies in engineering mega-systems that illustrate valuable lessons learned and highlight emerging practices, this book supplies the understanding and the tools needed to begin engineering, characterizing, and acquiring mega-systems across multiple dimensions.

More Information (embed hyperlink) http://www.crcpress.com/product/isbn/9781420076660

Engineering a Safer World: Systems Thinking Applied to Safety

Nancy G. Leveson

Published by: The M-T Pre-s

ISBN: 0262016621

Engineering has experienced a technological revolution, but the basic engineering techniques applied in safety and reliability engineering, created in a simpler, analog world, have changed very little over the years. In this book, Nancy Leveson proposes a new approach to safety that is more suited to today’s complex, sociotechnical, software-intensive world–based on modern systems thinking and systems theory. Revisiting and updating ideas pioneered by 1950s aerospace engineers in their System Safety concept, and testing her new model extensively on real-world examples, Leveson has created an approach to safety that is more effective, less expensive, and easier to use than current techniques. Arguing that traditional models of causality are inadequate, Leveson presents a new, extended model of causation (Systems-Theoretic Accident Model and Processes, or STAMP), then shows how the new model can be used to create techniques for system safety engineering, including accident analysis, hazard analysis, system design, safety in operations, and management of safety-critical systems. She applies the new techniques to real-world events including the friendly-fire loss of a U.S. Blackhawk helicopter in the first Gulf War; the Vioxx recall; the U.S. Navy SUBSAFE program; and the bacterial contamination of a public water supply in a Canadian town. Leveson’s approach is also useful in offering techniques for “reengineering” any large sociotechnical system to improve safety and manage risk.

More information (embed hyperlink)

Conferences and Meetings

2nd International Requirements Engineering Efficiency Workshop (REEW 2012)

March 19, 2012, Essen, Germany

PPI SyEN 43

Subscribe to PPI SyEN

PPI SyEN 134

PPI SyEN 133

PPI SyEN 132

PPI SyEN 131

FREE Original SE Articles and Industry News?

Subscribe to PPI

MORE About Us