Title: Engineering Fellow, PTC

First Name / Prenom: Matthew

Last Name / Surname: Hause

Conference Sponsor: PTC

Professional Affiliation: PTC

Matthew Hause

Matthew Hause is a PTC Engineering Fellow and MBSE Technical Specialist, the co-chair of the UAF/UPDM group a member of the OMG Architecture Board, and a member of the OMG SysML specification team.

He has been developing multi-national complex systems for over 35 years. He started out working in the power systems industry. He has experience in military command and control systems, process control, manufacturing, factory automation, communications, SCADA, distributed control, office automation and many other areas of technical and real-time systems. His roles have varied from project manager to developer. His role at PTC includes mentoring, sales presentations, standards development, presentations at conferences, specification of the UPDM profile and developing and presenting training courses. He has written over 100 technical papers on architectural modeling, project management, systems engineering, model-based engineering, human factors, safety critical systems development, virtual team management, product line engineering, systems of systems, systems and software development with UML, SysML and Architectural Frameworks such as DoDAF and MODAF.

He has been a regular presenter at INCOSE, the IEEE, BCS, the IET, the OMG, AIAA, DoD Enterprise Architecture, Embedded Systems Conference and many other conferences. He was recently a keynote speaker at the Model-based Systems Engineering Symposium at the DSTO in Australia.

Matthew studied Electrical Engineering at the University of New Mexico and Computer Science at the University of Houston, Texas.

The correct implementation of Model Management (MM) is highly subjective. It will depend on the type of project, number of participants, level of safety and mission criticality, industry sector, extent of system lifecycle covered, required security and secrecy levels, trust levels between the participants, volatility of requirements, number of requirements, number and types of tools with which to interact, etc. Consequently, there will be no single perfect MM solution. For example, a co-located integrated team working on a short modeling project needs only a single tool with a database. When other tools and geographical locations, participant companies etc. are added, the MM techniques used will vary.

When complete, OSLC will be a game changer as it will provide a means of sharing information between tools without the need for synchronizing mass quantities of information between them. This will reduce the duplication of information, increase traceability and speed up the development process. However, it will not work for all projects and environments. Phased projects where different aspects are implemented for different lifecycle phases will be challenging. Which version of the requirements or model needs to connect? How does one do impact analysis for a change if the change is always immediate? Traditional techniques such as synchronization of model elements between project tools will still be required when no secure link exists between the participants or the trust levels between the organizations is not sufficiently high. Different levels of security clearance between the areas of concern may require unique solutions. For example, on one project I worked on the specific requirements and metrics were classified, but the model was not. The model had to be exported to a CD, transported via “sneakernet” to the classified machine, imported and synchronized on a regular basis. After this, the CD was destroyed. This is an extreme example, but still very typical in Mil-Aero projects.

Large scale integrated projects will require industrial strength integrated databases rather than flat-file “database substitutes.” This is especially true for systems engineering projects where the cross cutting concerns require engineers to view, modify and link multiple parts of the model simultaneously. Engineers will often need direct access to the entire database. Integrated databases provide this whereas flat-file systems can cause lock-out situations where no one can make progress because everyone has different parts of the model locked. File-based tools work for small software projects, but will fail for systems engineering and architecture frameworks. In addition, versioning needs to be done at the model level to avoid version skew. Product Lines will complicate matters when the 150% model and the various product models all need to link to different requirements for unique projects. The Reusable Asset Specification (RAS) will provide a means to promote reuse and publish systems and software assets. RAS will be an essential tool for providing the long-sought goal of reuse for project developers within organizations. So, as a carpenter needs many tools to build a house, systems engineers will need different tools for MM.

Finally, MBSE is more than the SysML model, and a project is more than just MBSE. Requirements, CAD data, code, electrical and mechanical drawings, etc. would all need to be simultaneously check-pointed as well as re-creatable if a true project baseline was needed. As SysML 2.0 strives for holistic MBSE, MM needs to strive for holistic project baselines and configurations.