Systems Engineering Future and Quantitative Standards

1
Systems Engineering Future and Quantitative
Standards

• Existing Systems Engineering standards are
  qualitative
• management process descriptions
• What has made Engineering Professions Efficient?
• Integrated teams
• Rigorous design data
• Computer automated computation and checking
• Information capture once transform it as needed
• Inter-communication among businesses in the
  supplier
• chain with data exchange among their computer
  based tools

David W. Oliver dwoliver_at_mail.com
2
What is the context of Systems Engineering?
User/Owner/Operator
Acquisition Authority
Systems Engineering
Specifications
UML ISO SC7
Engineering Disciplines
3
In any Application Area

• Aircraft engines, Digital hardware, Hospital
  software, etc
• There is a supplier chain of businesses that
  exchange product data
• Each of these businesses may span many
  engineering disciplines
• Each business has its own tool sets
• The tools must exchange information

• Digital hardware may be one of a thousand items
  to be specified,
• designed, manufactured, integrated, shipped,
  maintained

4
AP210 Usage Standard Protocols Facilitate Data
Use
System Engineer
Package Data Supplier
Simulation Model Supplier
Requirements
Design Team
Assembly Vendor
Configuration Managed Corporate Data Interface
Process
ECAD
MCAD
Device Supplier
Fabrication Vendor
A Standard Data Model
5
AP210Product Structure Data
6
SEDRES AP-233?
Monolythic Model Dev
EC-part funded research projects
SEDRES
SEDRES-2
An ISO co-ordinated standards activity
AP-233
Modular Model Dev Harmonization
97
98
96
99
00
01
7
Consortium Project Value
2 MEURO (2M), 1/1/2000 for 18 months, over 17
person years effort (SEDRES-1 5.87 MEURO - 3
years - 44 person years effort)
8
When the next meetings take place

• AP233 Meeting Schedule
• - 2/19/01 Funchal, Portugal
• - 6/10/01 San Francisco, USA
• - 9/30/00 Fukuoka, Japan

9
AP233 Status

• AP233 Status
• - The AP233 model is based on the monolithic
  information
• model from the European funded SEDRES program.
• - SEDRES has ended its model development phase
  and is in
• a validation phase with a final report due in
  2001.
• - The AP233 team is
• 1. Taking over and editing the SEDRES
  documentation
• 2. Transforming the monolithic model to a modular
  model
• that uses existing parts of other ISO/SC4
  standards
• (This is an INCOSE recommendation from the May
  review)

10
AP233 Status

• AP233 Status
• 3. The modular AP233 module uses
• 3.1 Parts for SE management from Product Sata
  Management,
• PDM, standards
• 3.2 Parts for performance calculation from
  Engineering
• Analysis standards, (EACM)
• 3.3 Parts for configuration management from
  Product
• Life Cycle Support standards, (PLCS)
• 4. The AP233 team is now reviewing and
  harmonizing five
• models AP233, SEDRES, PDM, EACM, and PLCS
• 5. There is an increase in work at the time that
  formal funding
• is ending. Manpower is NEEDED

11
Plan for INCOSE/AP233 Liaison for 2001 1. INCOSE
Liaison to ISO AP233/SEDRES

• Conclusions and Plan Recommendations Get
  Manpower
• 1. Get INCOSE corporate and individual members
• to work directly in AP233 on AP233 core, PDM,
• EACM (performance), and PLCS (configuration
  mgmt).
• 2. Set up a second INCOSE review as soon as the
• documentation for SEDRES is stable and the
  modularization
• of AP233 with PDM, EACM, and PLCS is defined.
  Can not
• happen before spring 2001.
• 3. Continue liaison with AP233 at three 2001
  meetings.
• 4. Continue interactions with T-Board, Cab, TCs,
  MDSD-WG
• and TI-WG and expand to other interested
  working groups.

12
Plan for INCOSE/AP233 Liaison for 2001 1. INCOSE
Liaison to ISO AP233/SEDRES

• Work product schedule
• - It is premature to define dates for WD, CD,
  FDIS, and DIS
• until the documentation and modularity are
  better defined.
• - The speed with which these products are
  completed depends
• upon addition of adequate committed manpower
  to AP233.
• - A version of the SEDRES/AP233 Schedule is shown
  in
• the next slide. The timing is in flux.

13
Model enhancement, modularization and
harmonization
Update documentation
Update documentation
AP233
AP233 team takes over
Publish architecture
Map tables
Information Model WD-5
Information Model Corrections
Edited Model WD-5
SEDRES II
Develop information model
Develop interfaces
Validate
INCOSE informal model review window
Jan Feb Mar Apr May Jun July
Aug Sept Oct Nov Dec Jan Feb
Mar Apr May Jun Jul Aug Sept
Oct 2000

2001
Japan
Melbourne
Bordeaux
Charleston
Portugal
USA
INCOSE
14
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
Background The development of UML as an
international standard language for Software
Engineering is under the auspices of
Object Management Group, OMG. OMG has 731 member
companies and many hundreds of language competent
active participants The last technical week was
attended by 444 language process competent
engineers who spent their time working on
advances in UML and its application to fields of
interest
15
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
The workers develop, RFIs, RFPs, and they
evaluate response Submissions to the RFPs. The
Submissions are developed by consortia of
companies that want the work output as a standard
with tool support. UML 1.4 will become an ISO
standard by adoption The next major version is
UML 2.0 under development
16
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
Background UML 2.0 will not model physical
reality as needed for Systems Engineering it
will lack needed entities UML is a family of
languages which can be specialized to particular
application areas by adding needed entities to
create a UML Profile. Profiles are under
development in many other domains.
17
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
Background There is much discussion of using UML
directly for systems engineering, two tutorials
Minneapolis 2000, Systems Engineering, Vol. 3,
No. 4. Computer, current issue, has two articles
on generating specifications If software
engineering cannot get requirements in
rigorous model form, they will redo the systems
engineering adequately to generate that
information.
18
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
OMG has the resource, interest, momentum and
manpower to create standards for specification
without INCOSE input. The System viewpoint is
needed for specification creation. There is an
open invitation to INCOSE to lead in the
creation of a UML profile based on AP233
semantics.
19
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model

• Advantages of a UML Profile based on AP233
• Recognized INCOSE international leadership in
  modeling systems
• Bridge the systems/software gap, efficient
  requirements transfer
• Consistent international standards for Software
  and Systems
• Engineering
• Each discipline has the semantics it needs
• Information transfer among team members and
  among tools
• Consistent training

20
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
Conclusions and Plan Recommendations for UML
Profile 1. INCOSE establish formal liaison with
OMG by trading liaisons 2. INCOSE form an INCOSE
team to do/monitor work. Individual members
have indicated interest. Begin now by
defining the entities to be involved in the
profile, not all of AP233 is required. Scopes
problem. Develop an RFP for a UML Profile
based on AP233 semantics within the OMG
process and meeting structure. 3. Manpower is
NEEDED
21
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
3. Fund parts of the work - three possible
mechanisms 3.1 Fund in university setting
Explored because lowest cost, but personnel not
available for whole job. 3.2 Fund by
companies, members of both INCOSE and OMG,
assigning their personnel and providing time,
travel support and their company name
attached to documents. Past experience
suggests this will provide only some of the
manpower required, for scope and RFP. 3.3
Fund consultants such as EuroStep where there
exists the needed expertise to create the
technical drafts of submissions to the
RFP.
22
Plan for INCOSE/AP233 Liaison for 2001 2. A UML
Profile for the AP233 information model
4. Participate in accordance with OMG rules for a
profile. 4.1 Requires OMG membership company
participation 4.2 Requires substantial time
investment 4.3 OMG has documentation and
procedure standards
Optional RFI stage The TF writes an RFI and votes
to recommend issuance by its parent TC. The TC
votes to issue the RFI. The TF accepts, reads,
and analyzes responses to the RFI. Top TF
issues RFP, evaluates submissions Possibly using
information received via the RFI, the TF writes
and votes to recommend issuance of an RFP by its
parent TC. The AB approves the RFP. The TF's
parent TC votes to issue the RFP. On or before
the LOI deadline, one or more OMG member
companies submit LOIs. On or before the Initial
Submission deadline, which typically falls three
weeks before an OMG technical meeting week, all
or most of these companies submit initial
submissions.
23
Interested OMG members read the submissions, and
comment on them during the meeting (especially if
they find things they don't like, of course).
During the interim between this meeting and the
revised submission deadline, interesting things
may happen. The revised submission deadline may
be extended. There may be multiple deadlines for
revised submissions. On or before the revised
submission deadline, one or more revised
submissions may be submitted. OMG members read
and evaluate the revised submission (most likely)
or submissions (less likely). If most members
consider the submission worthy, a series of votes
begins. Top voting to Adopt an OMG
specification If the votes are to begin at the
meeting that immediately follows the revised
submission deadline, a procedural hurdle known as
the "vote to vote" is encountered. The TF
votes to recommend adoption to its parent TC.
The AB votes approval. The parent TC votes to
recommend to OMG's BOD. The BOD Business
Subcommittee (BSC) reports to the BOD on Business
Committee Questionnaire responses from the
submitters. If at least one satisfactory
response was received, the BOD votes to adopt the
specification. At this point, the submission
becomes an official OMG Adopted Specification,
but does not receive a release number. Top
24
finalization - getting ready for prime time The
TC charters a Finalization Task Force (FTF).
The FTF performs the first maintenance revision
on the specification, resolving issues submitted
to OMG, while simultaneously producing
implementations back in their companies. The
FTF-revised version of the specificaiton is
adopted as official OMG technology, through the
same series of votes as the original submission
(TF, AB, TC, and BOD). This time it receives a
release number, and is designated an available
specification. The document is edited into a
formal OMG specification. Typically, products
reach the market around this time too. Top the
OMG specification maintenance Cycle A recurring
maintenance cycle starts here. The TC charters an
RTF and sets deadlines for its report
and specification revision. . The RTF collects
and acts on issues submitted to OMG, producing a
revised specification. The revised specification
is adopted through the series of four votes. A
new RTF is chartered, and the process repeats.
Top Retiring Obsolete Specifications Obsolete
(not superseded) specifications may be retired
25
Plan for INCOSE/AP233 Liaison for 2001 Summary

• Continue AP233 Liaison
• Hold a second INCOSE review of AP233 in 2001,
  date TBD
• Increase participation in the AP233 Team, areas
  of interest
• - AP233 Core/SEDRES
• - Performance Modeling, EACM
• - Systems engineering management, PDM
• - Configuration management, PLCS
• Begin an AP233 Profile program
• - Formal liaison
• - Company membership and participation
• - Funding for creation of a RFP and response to
  the RFP

26
Plan for INCOSE/AP233 Liaison for 2001 3.
Validation project for the AP233 information model
1. The SEDRES validation does not include a
number of tools important to systems
engineering as performed by INCOSE
members. 2. Create an INCOSE sponsored activity
(funds manpower) to validate the AP233
model by developing prototype tool
interfaces, probably with PDES Inc support 3.
This work requires updates to the SEDRES
WD-5 model, and its harmonization with STEP AP
models. 4. This work must start after further
AP233 progress