Modelling Human Factors using the Systems Modelling Language

HFIDTC/2/WP2.8.9/1Version 2/ 24th September 2008In an example scenario, an operator in a GCS is monitoring a video feed from a UAV thathas been deployed to patrol an area where there is known enemy activity. He spots somesuspicious movement and moves the UAV and manipulates its cameras to get a betterview. He alerts his Commander who views the video on his own screen and concludesthat it shows a group of enemy soldiers taking up positions in a group of houses. TheCommander then determines the best Section of Ground Troops to engage the enemy,considering their location and current engagement status. They then contact the SectionCommander of the chosen Section with an engagement request and when this is acceptedthey send the video and map information locating the position of the enemy. As theGround Troops proceed to the engagement the GCS continues to monitor the enemy andown force positions and communicate enemy movements back to the SectionCommander.7.1 H-Fly SysML modelling examplesThis section provides examples of how the SysML can be used to model the H-Flysystem. For each example discussed there is a ‘Value Added’ section that highlights whathas been gained by constructing that particular aspect of the model, and how the use ofSysML has enhanced our understanding. Modelling is an iterative process and as the casestudy progresses, diagrams may be revisited and updated in the light of new information.It is important to maintain a glossary of terms used so that key terms are well defined andmay be understood by all people involved in the project. A glossary of the terms relevantto the H-Fly Project is provided in section 11 for this reason.7.2 Use Case Diagrams to model requirementsWe begin our case study at an early phase in the project lifecycle when we can onlymodel the system at a high level of abstraction and we need to start establishing systemlevel requirements. Perhaps the most appropriate way to start our modelling is with UseCases.Use Cases are behavioural diagrams representing the highest level of abstraction of thesystem and are useful for modelling requirements (Holt, 2004). They are therefore thebest entry point to start our modelling of the H-Fly system in the initial stages when weonly have a high level understanding of how the system will work and we do not have abaselined set of System Level Requirements. At this stage the model is necessarily highlevel; only high level system functions have been identified and manning, Roles andresponsibilities are yet to be defined (the Actors in the Use Cases below representorganisational units not operator roles). Typically in Systems Engineering the functionsor Roles of/within the system would be defined logically, independent of any physicalentities, which would then allow the development of requirements.Figure 7-2 shows the top level Use Case diagram for the H-Fly system.Use Case diagrams have the following components, which are labelled in Figure 7-2:15