Professor Peter Campbell Panel/Workshop SE for National Electricity System

Background The application being presented is from work sponsored by the Australasian Centre for Rail Innovation (ACRI) Application of MBSE techniques that assist stakeholders/users in examining the impact of the introduction of new technologies into heavy rail organisations Development of a “Portal” based architecture based on “concerns” Modelling has been based on a tailored version of the UAF

Addressing Rail Organisation Concerns Applications of MBSE techniques are able to do more than just capture information of and about a system Enables communication of concepts between stakeholders Prompts users for content to be developed and subsequently captured Can be structured to allow easy navigation through large complex representations But poor application of MBSE can result in Wasted effort, Poor information dissemination, or Models discarded because of lack of usability Care is needed to ensure the technology is applied appropriately

Multi-user Approach Typically a multi-user model Each user has a portal to access the information which they need Shared model spaces to enable provision of only specific (restricted) information to external organisations Organisation-specific model Needed as this model is intended to be used by several rail organisations that need to customise for their situations General model Used to roll out information to all organisations Contains general structures

Unified Architecture Framework Coverage

Need for a Formalised Approach Needs a formal approach to identify: What information needs to be modelled To what level of detail What information needs to be being shared By whom With whom In a manner that is replicable and flexible to the evolving needs of the stakeholder (users) We found that going back to the underlying principles that UAF was based upon provided the necessary structure: ISO/IEC 42010 – the Architecture Description Standard This allowed us to build a model that has the stakeholder needs explicit in the way the information is both captured and presented

Defining Viewpoints Architecture Frameworks are the generic structures that may be populated when creating a model of a system Using ISO 42010, viewpoints are created to frame the concerns of the framework’s stakeholders. Concerns can be considered to be the questions a stakeholder will ask of the model (or address using the model) UAF can define a large number of viewpoints

Defining Architecture Descriptions Architecture Descriptions are then developed by populating the Framework Model views are populated viewpoints that can then be used to address stakeholder’s concern(s) This creates an explicit relationship between the model content and the people who will use it This structure can then be leveraged to further tailor the model

The Process Identify the stakeholders and concerns in relation to each of the technologies considered in the tool; Identify the processes needed to address the concerns; Convert the processes into detailed tasks and allocate the viewpoints to each task; Development and description of the viewpoints; Examine the viewpoint needs (Identification of the information types required by stakeholders to enable them to address their concerns); Identify data structures required to support the viewpoint; Describe the manner in which the information will be presented and managed Identify interdependencies between viewpoints. Step 1 is intended to provide understanding of the needs, identify the stakeholders who will use the model, their concerns and questions that need to be answered. Step 2 examines how these questions need to be addressed. Step 3 converts the process into a discrete set of viewpoints and identifies how these viewpoints need to be arranged. Step 4 develops the viewpoints so that they contribute to addressing the various concerns. Step 5 integrates all viewpoints into a coherent AF that can be fully traceable back to the stakeholder’s needs.

But Usability also Requires Navigation How will users access the information pertinent to them? How will users be guided through or around areas which are shared?

Model Navigation to Help Address Concerns Merely allowing users to “find their way” is unsatisfactory Therefore: Customised portals must be created for each stakeholder/user to access their viewpoints Each concern is then presented so the user can select what aspects they are currently interested in, and Navigation is created to guide the stakeholder to the information that addresses their concerns Navigation is implemented either: By directly linking objects in models to destination diagrams; Better for linear processes By capture of processes in activity diagrams and linking the diagrams to the various concerns Better for branching processes or areas where different perspectives may be desired

Example – Competency Changes with the Introduction of Drones for Overhead Wire Inspection

Summary Applications of MBSE need to be focused on the information needs of the people who will use the model, and be usable This presentation shows how to utilise activity diagrams to capture the stakeholder processes and present views in a suitable order while maintaining the ability of stakeholders to move around the model as necessary ISO 42010 provides a useful relationship between the content and how it addresses the concerns of the stakeholders This relationship can be re-used to identify the appropriate views to be populated based on the concerns to be addressed ISO 42010 however doesn’t consider the order in which to present the views or how to guide the stakeholder in the use of the modelled information While some consider the freedom of models to “go where desired” as a positive, it can have issues: Unclear what the stakeholder has viewed (which may cause oversight) Some views constrain others which stakeholders need to be aware of

Discussion