260 likes | 277 Views
Explore the integration of engineering disciplines, information capture, and inter-communication among businesses to improve the efficiency of engineering professions. Discover how rigorous design data, computer automation, and standardized protocols facilitate data use and management.
E N D
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@mail.com
User/Owner/Operator Management Marketing BusinessStrategy Concept RFP Proposal Contract Management Info Management Info Digital Electrical Controls STEP ISO SC4 Logistics Software Chemical Mechanical Civil Communications Maintenance Manufacture What is the context of Systems Engineering? User/Owner/Operator Acquisition Authority Systems Engineering Specifications UML ISO SC7 Engineering Disciplines
Digital Hardware Digital Electrical Controls Systems Engineering Logistics Software Chemical Mechanical Civil Communications Maintenance Manufacture 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
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
Product Structure/ Part Connectivity • Functionality • Termination • Shape 2D, 3D • Single Level Decomposition • Material Product • Characteistis • Functional • Packaged Physical • Component Placement • Bare Board Geometry • Layout items • Layers non-planar, • conductive & non-conductive • Material product Configuration Mgmt • Identification • Authority • Effectivity • Control • Requirement Traceability • Analytical Model • Document References Geometry • Geometrically Bounded 2-D • Wireframe with Topology • Surfaces • Advanced BREP Solids • Constructive Solid Geometry Requirements • Design • Allocation • Constraints • Interface • Rules Design Control Technology • Geometric Dimensioning and Tolerancing • Fabrication Design Rules • Product Design Rules AP210:Product Structure Data
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
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)
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
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)
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
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, TC’s, MDSD-WG • and TI-WG and expand to other interested working groups.
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.
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
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
Plan for INCOSE/AP233 Liaison for 2001 2. A UML Profile for the AP233 information model The workers develop, RFI’s, RFP’s, and they evaluate response Submissions to the RFP’s. 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
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.
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.
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.
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
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
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.
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.
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
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
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
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