Jan 10, 2013 - but also the quality of a developed product (in terms of defect count). A model can .... provides automatic code generation which would be in synchronization with the design. ...... based systems using CppUnit test framework.
Master Thesis International Studies in Engineering (ISE)
Winter Semester 2010/2011
Model-based Software Development for the Helicopter's Pilot Assistance System using Problem Frames and SysML Meenakshi Deshmukh January 10, 2013
University of Duisburg-Essen, Germany · Faculty of Engineering CoCoS Department of Computational and Cognitive Science
Work Group Software Engineering Prof. Dr. Maritta Heisel supervised by: M.Sc. Florian-M Adolf, Institute of Flight Systems, DLR, Braunschweig, Germany
Acknowledgment At the nal step of my Master's degree, I oer my sincere gratitude to my guide Prof. Dr. Maritta Heisel and my supervisor Mr. Florian Adolf for providing me an opportunity to work with them for my master thesis. First and foremost I gratefully acknowledge Prof. Dr. Heisel for supporting my decision of pursuing master thesis at DLR, Braunschweig. She has been a great source of inspiration for me throughout my master's studies at the University of Duisburg-Essen, Germany. This thesis would not have been possible without her valuable support and guidance. The knowledge I earned from her lectures has immensely helped me in successfully carrying out my thesis work. The lessons learned from her would de nitely help me in further improving my software engineering skills. My special thanks to Mr.
Florian Adolf for giving me an opportunity to work with
an esteemed Research Institute "Deutsches Zentrum für Luft- und Raumfahrt (DLR), Germany".
He has always trusted in me and provided me an incredible support and
guidance during my thesis work. Working at DLR with the cutting edge technology and highly experienced colleagues was a great treasure for me. I have learnt many new things at DLR which will de nitely help me in my future career development. Last but not least, I would also like to thank my husband Kiran Gaikwad and my parents Geeta and Harish Deshmukh for their great support during my Master's course.
Meenakshi Deshmukh University of Duisburg-Essen, Germany
Contents List of Figures
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
1 Introduction
1
2 Theoretical Background
4
2.1
Uni ed Modeling Language
. . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Systems Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.1
Requirements diagram . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.2
Block De nition diagram
7
2.2.3
Internal Block diagram . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.4
Sequence diagram
8
2.2.5
State Machine diagram . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Problem Frames
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.1
Model Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.2
Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.3
Data-based Control . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4
DePES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.5 2.6
Online Re-Con guration and Supervision (ORCS) . . . . . . . . . . . . . . R
IBM Rational Rhapsody . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.7
Goal of the Master Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3 Phase 1: Requirements Analysis
16
19
3.1
Step 1: Describe system in use
3.2
Step 2: Describe system to be built . . . . . . . . . . . . . . . . . . . . . .
22
3.2.1
System Mission Statement . . . . . . . . . . . . . . . . . . . . . . .
23
3.2.2
ORCS Context diagram
. . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.3
ORCS Requirements . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.4
ORCS Requirements diagram . . . . . . . . . . . . . . . . . . . . .
27
Step 3: Decompose problem . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.1
Instantiated problem frames for ORCS . . . . . . . . . . . . . . . .
30
Step 4: Derive a machine behavior speci cation for each sub problem . . .
36
3.1.1
3.3 3.4
. . . . . . . . . . . . . . . . . . . . . . . .
19
ALLFlight Context diagram . . . . . . . . . . . . . . . . . . . . . .
20
3.4.1
ORCS Speci cations . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.4.2
ORCS Speci cations Diagram . . . . . . . . . . . . . . . . . . . . .
36
3.4.3
ORCS Sequence Diagram
37
. . . . . . . . . . . . . . . . . . . . . . .
4 Phase 2: Design
40
4.1
Step 5: Design global system architecture
4.2
Step 6: Derive speci cations for all components of the global system ar-
4.1.1
. . . . . . . . . . . . . . . . . .
40
Global System Architecture of ORCS . . . . . . . . . . . . . . . . .
41
chitecture 4.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Speci cation of Components of ORCS Global System Architecture
i
41 41
4.3
Step 7: Design a software architecture for all programmable components of the global system architecture 4.3.1
4.4
4.5
. . . . . . . . . . . . . . . . . . . . . . .
41
Software Components of ORCS . . . . . . . . . . . . . . . . . . . .
42
Step 8: Specify the behavior of all components of all software architectures using sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.4.1
47
Behavior of Software Components of ORCS
. . . . . . . . . . . . .
Step 9: Specify the software components of all software architectures as state machines 4.5.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ORCS State Machine Diagram
. . . . . . . . . . . . . . . . . . . .
5 Phase 3: Implementation 5.1
. . . . . .
52
ORCS Implementation . . . . . . . . . . . . . . . . . . . . . . . . .
53
6 Phase 4: Testing 6.1 6.2
ORCS Software Testing
. . . . . . . . . . . . . .
58
. . . . . . . . . . . . . . . . . . . . . . . .
59
Step 12: Integrate and test hardware and software 6.2.1
6.3
58
Step 11: Integrate and test software components 6.1.1
49
52
Step 10: Implement software components and test environment 5.1.1
48
. . . . . . . . . . . . .
61
ORCS Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . .
62
Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.3.1
64
ORCS Requirements Traceability . . . . . . . . . . . . . . . . . . .
7 Conclusion and Future work
66
Bibliography
68
ii
List of Figures 2.1
Classi cation of UML diagrams . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Classi cation of SysML diagrams . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Requirements diagram of Mobile Handset
7
2.4
Block De nition diagram of Mobile Handset: High level architecture
2.5
Internal Block diagram of Mobile Handset: ConnectionManagementBlock
2.6
Sequence diagram of Mobile Handset: Place Call Successfully
2.7
State machine diagram of Mobile Handset: Call Control
. . . . . . . . . .
10
2.8
Problem Frame: Model Building
. . . . . . . . . . . . . . . . . . . . . . .
12
2.9
Problem Frame: Transformation
. . . . . . . . . . . . . . . . . . . . . . .
13
2.10 Problem Frame: Data-based control
. . . . . . . . . . . . . . . . . . . . .
. . . . . . .
8 9 10
. . . . . . . . . . . . . . . . . . . . .
14
2.11 Mapping of DePES to V-Model . . . . . . . . . . . . . . . . . . . . . . . .
16
2.12 Structure of ALLFlight Project . . . . . . . . . . . . . . . . . . . . . . . .
17
3.1
Context diagram of ALLFlight Project . . . . . . . . . . . . . . . . . . . .
21
3.2
Context Diagram of ORCS
3.3
Requirements Diagram of ORCS with respect to HR
3.4
Model Building Problem Frame using SysML notations . . . . . . . . . . .
29
3.5
Transformation Problem Frame using SysML notations . . . . . . . . . . .
30
3.6
Data-based Control Problem Frame using SysML notations
31
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
Req.3.1_2.1
3.7
Instantiated Model Building Problem Frame for the requirement
3.8
Instantiated Transformation Problem Frame for the requirement
3.9
Instantiated Data-based Control Problem Frame for the requirement
Req.3.1_2.2 Req.3.1_2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 Speci cations Diagram of ORCS with respect to HR 3.11 Sequence diagram for the requirement 3.12 Sequence diagram for the requirement 4.1
Req.3.1_2.1 Req.3.1_2.2
24 28
32 33 34
. . . . . . . . . . . .
37
. . . . . . . . . . . . .
38
. . . . . . . . . . . . .
38
Req.3.1_2.1 . . . . . . component HAPDataContainer
Components Architecture for the requirement
. . .
43
. . .
44
. . . . . . . . . . . . . . . . . . . . .
44
4.2
Sub-Components Architecture for the
4.3
Interface description of
4.4
Components Architecture for the requirement
4.5
Global Architecture of
4.6
Sequence diagram showing behavior of the components of the requirement
4.7
Sequence diagram showing behavior of the components of the requirement
4.8
State machine diagram describing the behavior of the component
Req.3.1_2.1 Req.3.1_2.2 Controller
of
UDPCommIf ORCS
Req.3.1_2.2
. . . . . . . . .
45
after the merging of its all sub-components .
46
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ORCS
47 48
Sequence
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ORCS using a Block de nition diagram of SysML MainORCSBlock and UDPCommunicationBlock classes
49
5.1
Class Structure of
. . .
53
5.2
Description of
. . .
56
iii
6.1
Model-Based Testing Process
. . . . . . . . . . . . . . . . . . . . . . . . .
59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.2
DummyEC
6.3
Test Case for the requirement
. . . . . . . . . . . . . . . . . .
61
6.4
Input/Output data mapping results of ORCS testing . . . . . . . . . . . .
62
for Testing
Req.3.1_2.2
iv
List of Tables 2.1
Mobile Handset requirements
. . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Summary of Domain Knowledge after Step 1
. . . . . . . . . . . . . . . .
20
3.2
Summary of Domain Knowledge after Step 2
. . . . . . . . . . . . . . . .
26
3.3
Communication Requirements of ORCS
. . . . . . . . . . . . . . . . . . .
27
3.4
ORCS - HR Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.5
ORCS - HR Speci cations . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.1
Coding of Regimes based on the control signals and axes of a helicopter
50
6.1
Manual Requirements Traceability Table for the requirement
v
Req.3.1_2.1
.
6
65
Abbreviations ALLFlight
=
Assisted Low Level Flight and Landing on Unprepared Landing Sites
ALT
=
Alternative
AP
=
Arbeit Pakete
AS
=
Auÿensituation
CSP
=
Communicating Sequential Processes
DePES
=
Development Process for Embedded System
EC
=
Experimental Computer (on board the FHS)
ECC
=
Experimental Co-Computer (on board the FHS)
FHS
=
Flying Helicopter Simulator
HAP
=
Haupt Arbeit Pakete
HC
=
Haptic Cues
HR
=
Hubschrauber Regelung
OCL
=
Object Control Language
OMG
=
Object Management Group
ORCS
=
Online ReCon guration and Supervision
OXF
=
Object Execution Framework
PF
=
Problem Frame(s)
SC
=
Shortcomings
SCC
=
Sensor Co-Computer (on board the FHS)
SM
=
System Mission statement
SysML
=
Systems Modeling Language
TF
=
Trajektorienfolge
TG
=
Trajektoriengenerierung
UDP
=
User Datagram Protocol
UML
=
Uni ed Modeling Language
VC
=
Visual Cues
vi
Chapter 1 Introduction Software and cathedrals are much the same: First we build them, then we pray. Samuel T. Redwine
The use of computers and thus in turn the use of software has become an integral part of our lives. The use of software is not only limited to data processing but also extended in control systems. Starting from banking applications to aircraft controllers, software is everywhere. As the responsibility of processing is more on software, the reliability of a software is very important. The failure of software may result into a catastrophic failure of a system causing huge loss of valuable assets. Hence, the development of a reliable software is becoming more and more important. As compared to other technical disciplines, software engineering is comparatively young. Software development processes have not yet reached maturity level and therefore the software failure rate is very high. According to studies of the Standish-Group (CHAOS Research) [sta09], the success rate of failure free software is less than 50%. So in order to develop a defect free, robust and reliable software, many eorts have been initiated. Model-based software development is one of the most eective approach used for software development. The modeling techniques are already proved to be very useful in the other elds like civil and mechanical engineering and now it is becoming a promising technique in software engineering too. The reliability of software can be improved by using explicit model based tool supported development processes. Modeling not only improves the e ciency of a software development process but also the quality of a developed product (in terms of defect count). A model can be de ned as a simpli ed representation of a system intended to enhance our ability to understand, predict and possibly control the behavior of the system [Nee87]. The modeling technique involves visual representation of the dierent aspects of a system to be developed. Uni ed Modeling Language (UML) [OMG07] is the most widely used language for software modeling. UML consists of 13 diagrams which are used to model the structure and the behavior of a software system. However, there is no direct notation available in UML for stating the requirements. UML is software centric and does not provide eective representation for systems containing software plus non software components. With the increasing use of embedded systems, software components are no longer running in isolation. The scope of a word system is extended to include software plus non software components like hardware, personal, facilities etc. Thus, UML is not suitable for the system engineers who are interested in modeling not only the software but also the whole system. This gives rise to Systems Modeling Language (SysML) [Obj10] which is an extension to UML. SysML consists of a subset of UML diagrams with addition of a Requirements
diagram and a Parametric diagram.
Here requirements can be stated with the help
of a requirements diagram and a parametric diagram represents constraints on system property values such as performance, reliability, and mass properties. Hence, it serves
1
Chapter 1 Introduction as a means to integrate the speci cation and design models with engineering analysis models [Obj10]. However, both UML and SysML are design oriented. SysML also lacks methodological support. These modeling languages do not cover capturing of domain knowledge, problem descriptions, sub-problems decomposition and domain relationships. The requirements analysis phase is not e ciently modeled. According to C. Jones [Jon91], about 50 percent of serious errors are made during design phase of software development (25 percent during implementation) and about 30 percent of medium class errors are made during software design phase (30 percent during implementation).
The reason behind these errors in
implementation is due to the errors in design phase and the errors in design phase are due to the errors in requirements analysis. This leads to the need for a systematic and a rigorous requirements analysis approach. One such approach called Problem Frames (PF) is proposed by Michael Jackson [Jac01]. PF is a kind of a pattern that captures and de nes a commonly found class of simple subproblem. A given complex problem consists of a number of small simple sub-problems. For example, consider a patient monitoring system [Jac01, p.
1].
The given problem
consists of dierent sub-problems like capturing information from analog devices, setting the parameters per patient, entering patient's information, triggering a signal to nurse station etc. Jackson has proposed ve basic problem frames which covers commonly found sub-problems such as required behavior, commanded behavior, information display, simple
workpieces and transformation. Some more problem frames are proposed by Côté et al. + in [CHH 08] such as commanded transformation, data-based control etc. based on the dierent combinations of participating domains. Now the underlying sub-problems of the patient monitoring system problem could be classi ed into the above mentioned problem frames which represents a class of problem. For example, entering patient's information can be tted into simple workpieces.
Similarly entering book information in case of
library management system will also come under the class of simple workpieces. Thus, PF provides an e cient decomposition and structuring of the underlying simple subproblems. It facilitates reuse of already proven knowledge which makes the requirements analysis easier. The context diagram [Jac01, p. 20] explores the relation between software and the real world in which it would be integrated.
This gives more understanding
about the problem to be solved and the participating domains.
Strong requirements
analysis results into an e cient software design and an implementation with less number of defects.
Despite of all these advantages, problem frames are less adapted in the
industry because of the lack of linguistic support.
There are no standard notations
available for PFs as in the case of UML and SysML. Also there are no standard tools available for checking the syntax and the semantics of PFs. With this background, we would like to propose a software development approach in this thesis work which combines problem frames and SysML together. The combination of SysML and problem frames was rst introduced by Colombo et al. ([Col07], [Col08] and [Col10]).
However, the suggested approach does not fully comply with Jackson's
problem frames notations. The suggested notation does not take full advantage of SysML diagrams such as a requirements diagram. The approach does not cover complete software development process and is still design oriented. Hence an appropriate method, which not only covers all the phases of software development but also can integrate SysML and problem frames is needed.
Development Process for Embedded System (DePES)
[Hei08a] provides a systematic software development method based on the international software development standards.
DePES consists of twelve steps which covers all the
phases of software development that are requirements analysis, design, implementation
2
Chapter 1 Introduction and testing. Problem frames are already integrated in DePES methodology. In this thesis work, the combination of SysML and PF would be integrated with DePES. DePES would provide strong methodological support for SysML. Especially the use of PFs would help in carrying out an eective requirements analysis with SysML and nally SysML would provide standard notations to PFs. As a result of combination of SysML and PFs with DePES, a synchronized homogeneous model of software would be created which consists of all the artifacts created during the development of a software.
DePES covers the
development of both hardware and software components. But the scope of this thesis is restricted only to software development. The proposed approach is veri ed by applying it to the development of the helicopter's pilot assistance system named as Online ReCon guration and Supervision (ORCS). ORCS is a control software and it is a part of ALLFlight project at Deutsches Zentrum für Luft- und Raumfahrt (DLR), Germany [Ham08]. In order to provide an assistance to the helicopter's pilot, ORCS builds a model of real world based on the inputs from the dierent components of a helicopter. ORCS processes the data received from the dierent components of a helicopter and sends back the results to the respective components. The development of ORCS like complex software is always a big challenge. We are trying to accomplish it by using an approach based on problem frames, SysML and DePES as suggested in this thesis work. The thesis report starts with the theoretical background in Chapter 2 which is required for the sound understanding of the proposed approach. Then in Chapter 3, the requirements analysis phase of software development would be introduced. This chapter includes the rst 4 steps of DePES. The main emphasis is given to the adaption of SysML diagrams and notations to the context diagram and problem frames. Chapter 4 describes Steps 5 to 9 of DePES which cover a systematic method for modeling system architecture and inter-component interactions using SysML diagrams. Chapter 5 provides guidelines to the implementation that is programming part of the software development. Finally Chapter 6 covers last 2 steps of DePES which describes testing and integration of all components in a system. The report ends with the conclusion and future work in Chapter 7.
3
Chapter 2 Theoretical Background This chapter gives an overview of dierent technologies and methodology which form the basis for the software development approach proposed in this thesis work. This chapter starts with the description of two important modeling languages UML and SysML. Then the concept of problem frames which is very useful for an eective requirements engineering is described. Further DePES a systematic method of software development R
and IBM Rational Rhapsody a model based development tool have been introduced. The goal of this master thesis would be set at the end of this chapter.
2.1 Uni ed Modeling Language Uni ed Modeling Language (UML) is a standardized general-purpose modeling language in the eld of software engineering [OMG07]. It provides dierent types of diagrams in order to visually model the structure and the behavior of an application. UML consists of 13 diagrams out of which 6 diagrams are used to model the structure whereas the remaining 7 are used to model the behavior of software. A further classi cation of the UML diagrams is shown in Figure 2.1. Using these diagrams the static and dynamic aspects of a software system can be described. UML is now becoming a de facto industry standard. It is independent of any methodology and implementation platform. UML helps a developer to work at dierent levels of abstraction.
For example, a developer can start with a use case diagram in
order to de ne actors, systems and their roles. Then a sequence diagram can be used to capture the interactions between actors and other components of a system. A class diagram gives an overview of the structure of a software.
With a composite structure
diagram, a developer can de ne both the internal and the external interfaces between the components and with a object diagram, a run time instance can be modeled. UML provides automatic code generation which would be in synchronization with the design. UML also provides linking between dierent models which assures coherence between them. Such a systematic development of software using UML modeling has been proven to be cost eective and e cient in terms of less defect rate [Wat08]. However, UML is highly software design oriented. It does not provide any notation for specifying requirements and performing requirements analysis. The interrelation between the requirements and requirement traceability is also di cult with UML. It is well suited for applications consisting of only software components like a library management system but not well suited for specifying complex systems that include software and non-software components (hardware, processes, personal etc.) like embedded systems. A new modeling language named Systems Modeling Language (SysML) has been evolved by Object Management Group (OMG) [omg] in order to overcome UML limitations in the eld of systems engineering.
4
Chapter 2 Theoretical Background
Figure 2.1: Classi cation of UML diagrams
2.2 Systems Modeling Language OMG Systems Modeling Language (SysML) is a UML-based language for graphical modeling of complex systems that include software, hardware, information, processes, personnel, and facilities [Obj10]. It supports the speci cation, analysis, design, veri cation and validation of a broad range of systems. SysML consists of 9 diagrams. Their classi cation is shown in Figure 2.2. As shown in Figure 2.2, SysML consists of 7 out of 13 UML diagrams with the addition of Requirements and Parametric diagrams. Use case, sequence, state machine and package diagrams are reused directly from UML. Class diagram and composite structure diagram in UML are extended as block de nition and internal block diagrams in SysML respectively. The activity diagram in UML has also been modi ed via activity extensions in SysML. The newly added requirements diagram in SysML provides a way to specify requirements and relations between them and a parametric diagram shows parametric constraints between structural elements. It is useful for the performance and quantitative analysis. Thus, SysML allows a developer to model structure, behavior, requirements as well as properties of a system. Now we look into the details of requirements, block de nition, internal block, sequence and state machine diagram as they would be used in our proposed developmental approach. In order to illustrate the usage of these diagrams an R
example of the development of a mobile handset from IBM Rational Rhapsody systems engineering tutorial [IBM09] is used.
5
Chapter 2 Theoretical Background
Figure 2.2: Classi cation of SysML diagrams
2.2.1 Requirements diagram In UML, modeling starts mostly from the design phase. However, in SysML, modeling starts from the requirements analysis because of the requirements diagram. Requirements state the expected behavior/results from the system which we are going to build. Requirements are stated by the customer. Requirements diagram graphically shows the textual requirements (both functional and non-functional) and relationship between them. Requirements diagram captures requirements hierarchies and requirements derivation.
It
also enables linking between requirement and other design phase diagrams. It provides a bridge between the typical requirements management tools and the system models. It helps in having a clear understanding about the requirements between a developer and a customer which results into an e cient requirements analysis. For example, consider an example of the development of a mobile handset. Usually the customer provides textual description of his/her requirements as shown in Table 2.1. Name
Requirements
Req.4.0
The mobile shall be able to receive data calls at the rate of 128 kbps.
Req.4.1
The mobile shall be able to send data at the rate of 384 kbps.
Req.4.2
The mobile shall be able to receive streaming video at 384 kbps. Table 2.1: Mobile Handset requirements
From the requirements stated in Table 2.1, a developer can draw a requirements diagram with addition of relationship between the requirements as shown in Figure 2.3. Requirements diagram provides dierent types of relations such as composition, derive, verify,
6
Chapter 2 Theoretical Background satisfy, trace and decompose. A composition is a form of aggregation. An Aggregation is a special form of association that speci es a part-whole relationship from an "aggregate" (whole / source) to a "component part" (target). a requirement into sub-requirements.
It can be used to decompose
A derive relationship is a trace dependency be-
tween a derived requirement and a source requirement, where the derived requirement is generated or inferred from the source requirement. A verify relationship is a trace dependency between a supplier requirement and a client test case that determines whether a system ful lls the requirement or not. A satisfy relationship is a dependency between a supplier requirement and a client model element that ful lls the requirement. A trace relationship traces a requirements to an element that realizes it. The other elements of the requirements diagram such as a constraint can be used to state conditions, a com-
ment can be used for expressing extra details and a problem can be used to express unresolved/uncleared/incomplete questions/information.
Figure 2.3: Requirements diagram of Mobile Handset
Using a requirements diagram, a developer can easily convey his/her understanding about the customers requirements. Because of requirements diagram, requirements become an integral part of the system architecture. A customer can verify it and misinterpretations can be avoided at a very early stage. This helps in performing systematic requirements analysis.
2.2.2 Block De nition diagram A block de nition diagram is an extension to the class diagram of UML. It provides a unifying concept to describe the structure of an element or a system. A block can be used to model software as well as non-software components. It can be used to represent physical components of structure, for example hardware, software, data, procedure, facility
7
Chapter 2 Theoretical Background and person. Depending on the level of abstraction, a block can be lled with details like properties, operations, constraints, allocations of activities and requirements that the block satis es. Block de nition diagram describes the relationship among blocks (e.g., composition, association, classi cation).
So it is more commonly accepted by system
engineers. Figure 2.4 shows the high level architecture of a mobile handset using a block de nition diagram.
Figure 2.4: Block De nition diagram of Mobile Handset: High level architecture
2.2.3 Internal Block diagram An internal block diagram is used to show the internal structures of components shown in the corresponding block de nition diagram, including their parts and connectors. Internal block diagram is an extension of composite structure diagram of UML. In this diagram, both internal and external interfaces of the components are described using ports.
It
also describes the ow of data and control between the parts of a component. Figure 2.5 shows internal block diagram of a component 'ConnectionManagementBlock' shown in Figure 2.4.
2.2.4 Sequence diagram A sequence diagram describes the interactions between the dierent model elements of a system like actors, objects and processes using messages. It models the runtime behavior of a system.
Sequence diagrams provide many mechanisms such as alternative, loop,
condition and ref etc. which help in modeling complex scenarios. Sequence diagrams can be drawn in every phase of software and at dierent level of abstraction. A comparison
8
Chapter 2 Theoretical Background
Figure 2.5: Internal Block diagram of Mobile Handset: ConnectionManagementBlock
between the messages of sequence diagrams drawn in the dierent phases but of the same scenario would be helpful in nding the coherence between the dierent phases. Figure 2.6 describes one of the scenarios of mobile handset development named as Place Call Successfully.
2.2.5 State Machine diagram Like a sequence diagram, a state machine diagram is also used to model the run time behavior of a system. It describes the system's behavior as sequences of states between which a component could switch in order to respond to a particular event. In general, an
event is an occurrence in time and space that has signi cance to a system. So an event could be an occurrence of a condition or reception of a signal/message etc.
An event
triggers the state transition. A state can be optionally represented using an entry action, an exit action, and do-activity sub-states. or concurrent states.
There could be single, nested, sequential
This event based state transition represents the life cycle of a
component. Figure 2.7 represents state machine diagram of Call Control block of mobile handset. It describes possible state transition in response of occurrence of a particular event. A stereotype is a mechanism which is used in SysML diagrams in order to customize the representation. We will look into its usage in Chapter 3 where we try to give standard notations to problem frames using SysML. However, SysML lacks in methodological support. SysML also needs an explicit way for capturing domain knowledge, problem description, sub-problem decomposition and domain relationships. SysML oers linguistic means to describe and allocate requirements
9
Chapter 2 Theoretical Background
Figure 2.6: Sequence diagram of Mobile Handset: Place Call Successfully
Figure 2.7: State machine diagram of Mobile Handset: Call Control
10
Chapter 2 Theoretical Background but does not provide means to de ne structure and classi cation of requirements. So a strong mechanism is needed for the requirements and domain analysis.
2.3 Problem Frames The requirements analysis is the base of any product development. Understanding the nature of a problem before getting into its solution is necessary for a robust software. The description of a problem context that is the description about where the problem is located along with the participating domains is also very important. Most of the times software projects are interdisciplinary and hence, along with the software development knowledge, corresponding domain knowledge is also essential. Unfortunately, most of the times the main emphasis is given to software implementation and background knowledge such as problem description and domain knowledge are not e ciently handled which results into software failure. Problem Frames (PF) are invented by Michael Jackson [Jac01] provides a concrete way for performing the requirements engineering. Jackson [Jac01] describes PF as follows:
A problem frame is a kind of pattern. It de nes an intuitively identi able problem class in terms of its context and the characteristics of its domains, interfaces and requirement. PFs focus on What is a problem?
without going into the details of How problems
can be solved?. The idea behind PFs is to classify and analyze the common types of simple problems. M. Jackson [Jac01, ch. 3] states that the main problem could look like altogether dierent than other but the sub-problems could be of same type. For example, consider a library management system and an aircraft controller. If we look at a very high level, given problems fall into two dierent categories.
However, when we start
decomposing the main problem, we could realize that they consist of sub-problems of similar type such as reading from a le, accepting commands from a user and displaying results to the display. Thus we can re-utilize our knowledge in solving sub-problems of a same class in two dierent main problems. M. Jackson [Jac01, ch.
4] invented ve basic frames called Required behavior, Com-
manded behavior, Information display, Simple workpieces and Transformation.
These
basic frames are too simple and many sub-problems can not directly t into them. Hence, each of the basic frames have several dierent avors and variants that can accommodate realistic variations. Jackson does not claim that his frames are complete. The idea of
+
the problem frame is further extended by Côté et al. [CHH 08] based on the possible combinations of constrained and referenced domains. In this paper, some more problem frames are discovered based on the commonly occurring sub-problems. The connection between the domains is shown using a line that connects the participating machine and problem domains. It is called an Interface. Each interface represents the
phenomena that are shared between the domains.
The phenomena could be events,
actions or operations that occur in the environment.
They can be either observed or
controlled by the environment or the machine. Phenomena are largely classi ed into two categories, Causal and Symbolic. The causal phenomena are events or roles or states that directly caused or controlled by some domain. For example, pressing a button inside a elevator. The symbolic phenomena are values or truths. For example, reading a value from a database. A problem can only be tted to a problem frame if the involved problem domains belong
11
Chapter 2 Theoretical Background to the domain types [Jac01, p. 83] speci ed in the frame diagram. In the following sub sections, three problem frames namely Model building, Data-based control and Transfor-
mation are brie y described as they are further used in the development of ORCS.
2.3.1 Model Building A model building frame handles the sub-problem of capturing the information about the real world. Real world is an autonomous causal domain. For example, real world could be a running car in case of an odometer display or a working lift in case of a lift oor display etc.
In many situations like stated above, the current information in terms of
value or state of the real world is needed. Such information is then used for a display or for future estimation. Model building frame explicitly translates causal phenomena in the real world into lexical (symbolic) phenomena that a machine can manipulate. The frame diagram for the model building problem frame is shown in Figure 2.8.
Real World C
RW!C3
RW!C1
Modeling Real world Modeling Machine
MD!Y4
MM!E2
Model X
Figure 2.8: Problem Frame: Model Building As shown in Figure 2.8, there are two participating domains in a model building subproblem. One is a
Real World which is a causal domain and other is the Model which is a
lexical domain. Lexical domain describes physical representation of a data and causal do-
RW!C3 corresponds Real World. The symbolic phenomenon MD!Y4 corresponds to lexical representation of RW!C3 in the Model [Jac01, p. 83]. The Modeling Real World is a requirement shown in a dashed oval which states the corresponding mapping between the Real World and Model. The Modeling Machine represents software that needs to be developed for solving the given requirement. Here, the Modeling Machine does the mapping between the causal phenomena RW!C1 received from the Real World and the Model using the commands MM!E2. The dashed line connecting the Real World and the requirement Modeling Real World has no arrow. This means that the requirement only refer to phenomena RW!C3 of Real World, but do not constrain them. On the other main means its properties are predictable. The causal phenomenon to actual event occurring in the
12
Chapter 2 Theoretical Background Modeling Real World and the Model has MD!Y4 is constrained by the requirement.
hand, the dashed line between the requirement an arrow, which means that the phenomenon
2.3.2 Transformation The idea behind a transformation frame is described as follows:
There are some given computer-readable input les whose data must be transformed to give certain output les. the output data must be in a particular format, and it must be derived from the input data according to certain rules. The problem is to build a machine that will produce the required outputs from inputs [Jac01, p.99]. A transformation frame mainly deals with a data manipulation sub-problem. For example, generating HTML for a web page from a server database and a query or generating a report from a database. The frame diagram for transformation is shown in Figure 2.9.
Input IN!Y3
IN!Y1
X
IO Relation
Transformation Machine
OP!Y4
TM!Y2
Output X
Figure 2.9: Problem Frame: Transformation
Input and Transformation Machine represents a software that needs to be developed. A requirement is described using IO Relation shown in a dashed oval. The lexical domain Input symbolically represents the data that needs to be processed. The Input can be a le or a database or a variable which is holding some data. The Transformation Machine reads and extracts data from the Input using the symbolic phenomena IN!Y1. The IO Relation describes rules about the processing of Input data. The Transformation Machine executes the processing rules on the Input data and stores the result as an Output data using the symbolic phenomenon TM!Y2. The lexical domain Output can either be a le or a database or a variable. The symbolic phenomena IN!Y3 and OP!Y4 are the abstract representations of Input and Output data respectively. The dashed arrow line from the requirement oval to the Output domain represents that only the Output domain would As shown in Figure 2.9, the frame diagram contains 2 lexical domains namely
Output.
The
13
Chapter 2 Theoretical Background IO Relation requirement. The dashed line connecting the Input and the requirement IO Relation has no arrow. This means that the requirement only refers to phenomena in the Input, but does not constrain them.
be constrained by the rules de ned in the
2.3.3 Data-based Control +
A data-based control problem frame is introduced by Côté et al. [CHH 08]. The concept behind this frame is to handle a sub-problem that deals with controlling of a causal domain by a machine based on some prede ned value. This frame can be regarded as a required behavior frame [Jac01, p.77], because lexical domains are special causal ones. However, a separate frame is appropriate since additional aspects (e.g., design of the data) have to be considered to solve such problems. The frame diagram for data-based control is shown in Figure 2.10.
Controlled Domain C
CD!C3
DCM!C1, CD!C2
Data-based Controlled Behavior
Database Control Machine
DB!Y4
DB!Y4
Database X
Figure 2.10: Problem Frame: Data-based control
As shown in Figure 2.10, there are two participating domains in data-based control frame diagram. One is a
Controlled Domain
havior of a
DB!Y4
Controlled Domain
Database CD!C3 corresponds to the required be-
which is a causal domain and other is the
which is a lexical domain. The causal phenomenon
as described by a requirement. The symbolic phenomenon
Database. The required beData-based Controlled Behavior
corresponds to the data represented by the domain
havior of
Controlled Domain is constrained by DB!Y4.
The
is the requirement shown in a dashed oval which states the correspondence between the values in the Database and required behavior of the Controlled Domain. The Database Control Machine represents a software that needs to be developed for solving the given requirement. Here, the Database Control Machine reads the data from Database using the phenomenon DB!Y4. According to the value read from D!Y4, the machine instructs behavior of the Controlled Domain using the phenomenon DCM!C1 based on the requirement. The Controlled domain might send feedback to the Database control Machine about
14
Chapter 2 Theoretical Background its state using the phenomenon
CD!C2.
The instantiation of the above stated frames based on the realistic problem would be covered in Chapter 3 in the context of ORCS development.
2.4 DePES Development Process for Embedded System (DePES) is proposed by Heisel et al. [Hei08a]. It consists of 12 steps which covers the complete development process starting from the requirements analysis to the testing of both software and hardware components of a system. In DePES, modeling is used for problems, speci cations, architecture and component behavior. The twelve steps of DePES are as follows: 1. Describe system in use 2. Describe system to be built 3. Decompose problem 4. Derive a machine behavior speci cation for each sub-problem 5. Design global system architecture 6. Derive speci cations for all components of the global system architecture 7. Design an architecture for all programmable components of the global system architecture that will be implemented in software 8. Specify the behavior of all components of all software architectures, using sequence diagrams 9. Specify the software components of all software architectures as state machines 10. Implement software components and test environment 11. Integrate and test software components 12. Integrate and test hardware and software DePES uses a context diagram and problem frames to model a problem. The problem means our requirements. UML diagrams are used in DePES in order to model the architecture and behavior of a system. The usage of patterns in DePES facilitates re-use of existing knowledge and (partial) automation. DePES supports certi cation according to safety- and security standards ISO/IEC 61508 [Int00] and Common Criteria (CC) [Int06]. It also supports the V&V (veri cation and validation) model of software development. Veri cation ensures that the speci cation is complete and mistakes have not been made in implementing the model. Validation ensures that the model meets its intended requirements in terms of the methods employed and the results obtained. Validation conditions that are speci ed for every step in DePES give a systematic way of testing and nds defects in the early stages of development as suggested by the V&V model. The relation between DePES and V model is depicted in Figure 2.11 which provides us the sequence of execution of DePES steps and interrelation between the steps [Hat06]. As stated earlier in the introduction, hardware component development of a system is not in the scope of this work. Hence, the main focus is given to the software development of a system and thus Steps 5 and 12 of DePES would not be executed.
As pointed
out earlier, requirements analysis and other development phases are modeled separately in DePES using dierent notations and tools. Though validation conditions suggested in DePES try to detect defects in early stages and reduce gap between analysis and
15
Chapter 2 Theoretical Background
Figure 2.11: Mapping of DePES to V-Model
other phases, it still can not provide a homogeneous model of a whole system with seamless development.
In this thesis, we propose to construct a homogeneous model
which links all the artifacts created in all phases of software development and veri es the coherence between them. Such a homogeneous model will facilitate a smooth transition from requirement elicitation to design, implementation, testing and maintenance phase. In the following chapters, each step of DePES would be described in detail along with the integration of SysML and PF in order to achieve a homogeneous model as stated above.
2.5 Online Re-Con guration and Supervision (ORCS) The Deutsches Zentrum für Luft- und Raumfahrt (DLR),Germany (Institute of Flight Systems) is currently working on Assisted Low Level Flight and Landing on Unprepared Landing Sites (ALLFlight) project. In ALLFlight, a helicopter's pilot assistance system would be developed which allows the intuitive operation of a manned helicopter from start to landing on unprepared landing sites and an intermediate low level ight in the presence of obstacles in a degraded visual environment. Such a pilot assistance system provides advanced visual and tactile cues, intelligent control augmentation, reduces the pilot workload and increases his/her situational and mission awareness. In order to achieve the goals of ALLFlight, the system is divided into 6 dierent components working on dierent aspects as stated above. The structure of the components that are composing ALLFlight project is shown in Figure 2.12. The main components are termed as Haupt Arbeit Pakete
1 (HAP). Each HAP is further divided into sub-
2 components termed as Arbeit Pakete (AP). The 6 HAPs are named as Umgebungsmod-
1 2
English: Main Work Units English: Work Units
16
Chapter 2 Theoretical Background 3 , Trajektoriengenerierung 4 (TG), Regelung 5 , Hu6 and Project man Machine Interface (HMI), Flugeigenschaften, Mission und Operation
ell Erstellung und Hindernisdetektion
Management. These HAPs (except Project Management) are implemented either on Experimental Computer (EC), Experimental Co-computer (ECC) or Sensor Co-Computer (SCC) which are the on board computers of the Flying Helicopter Simulator (FHS). As a part of this thesis work, AP 5.3 Mission und Ablaufsteuerung of the ALLFlight project is developed for the veri cation of the proposed development approach.
This
sub-component of the ALLFlight project is developed under the name 'Online ReCon-
guration and Supervision' (ORCS). The main objective of ORCS is to model the basic behavior of the overall ALLFlight system. It integrates complex and critical automation behaviors using parameters provided by the other components of ALLFlight, monitors communication between dependent components, con gures each component and nally builds a decision making system. ORCS does not have direct interface with the hardware components of the helicopter. Instead it gathers the information via other APs which are directly interfaced with the hardware components of a helicopter. For example, in order to model current environment situation, ORCS receives data captured by dierent sensors via the component HAP 1/ AP 1_4.
ALLFlight
HAP 1 Umgebungsmodell Erstellung und Hindernisdetektion
HAP 2 Trajektoriegenerierung
HAP 3 Regelung
HAP 4 HMI
HAP 5 Flugeigenschaften, Mission und Operation
AP 1.1 Erfassung der sensordaten
AP 2.1 Take-off
AP 3.1 Modelbasierte Basis Regelung
AP 4.1 Visual Cues
AP 5.1 Flugeigenschaften in DVE
AP 1.2 Gelandedaten generierung
AP 2.2 Enroute
AP 3.2 CMD modelle und Upper modes
AP 4.2 Haptic Cues
AP 5.2 Regime Recognition
AP 2.3 Landing
AP 3.3 Trajectoriefolge und NOE flight
AP 4.3 Envelope Protection
AP 5.3 Mission und Ablaufsteurung
AP 3.4 Intutive control
AP 4.4 DVE Realisierung in simulation
AP 5.4 Operationalle Aspekt
AP 1.3 Informationfusion
AP 1.4 Hindernisdetektion
HAP 6 Projekt Management
Figure 2.12: Structure of ALLFlight Project
In the rst phase of ORCS development, the requirements gathering and analysis from some components has been started but it was performed without using any systematic requirement engineering approach. As a result, the requirements are hard to understand and the traceability of the requirements is di cult. According to the terminology used in a requirements engineering, requirements and speci cations are two dierent statements. A requirement states the desired characteristics of a system while speci cation states how should machine (system) acts so that it ful lls the requirements. Speci cation is a
3
English: English: 5 English: 6 English: 4
Environment modeling and obstacle detection Trajectory Generation Controller Flight properties, mission and operations
17
Chapter 2 Theoretical Background implementable requirement and it is derived from the given requirement. In case of ORCS development, this dierence was not considered. Directly the speci cations of ORCS are stated. Dependencies between the requirements are not captured. Facts and assumptions about the domain knowledge are not stated. Maintaining changing requirements is also very di cult. Currently the core functionalities of ORCS and its communication with components are modeled using UML and implemented using C++ but separately. ORCS design model and its implementation are not fully synchronized. In order to overcome the above stated problems, there is a need to apply a systematic process as proposed in this thesis for the development of ORCS in order to get e cient and reliable results. In this report, ORCS would be used as a case study. We apply the suggested concept to ORCS development in order to verify their applicability. R
would be developed using IBM Rational Rhapsody ([IBM08a] and [IBM09]).
ORCS
2.6 IBM Rational Rhapsody R R
[IBM08a] is a visual development environment for systems
IBM Rational Rhapsody
engineers and software developers creating real-time or embedded systems and software. Rhapsody helps diverse teams collaborate to understand and elaborate requirements, abstract complexity visually using industry standard languages (UML, SysML, AUTOSAR, DoDAF, MODAF and UPDM), validate functionalities early in development, and automate delivery of high quality products.
Rhapsody uses graphical models to generate
software applications in various languages including C, C++, Ada and Java. Rhapsody is available in various editions satisfying various needs of developers.
Rhapsody De-
veloper edition provides complete model-driven-development environment for technical, real-time, or embedded systems. Rhapsody Designer for Systems Engineers edition analyze, architect, simulate systems with model driven development using UML, SysML, UPDM. Rhapsody Architect for Software can be used to develop, architect embedded systems and real time software using model driven development. Rhapsody Architect for Systems Engineers analyzes system engineering requirements with model driven development using UML, SysML, UPDM. The modeling of test cases and automated testing can be done using IBM Rhapsody with an add-on Test Conductor. After performing the initial requirements analysis of ORCS, we decided to develop ORCS using SysML and R
C++. Thus IBM Rational Rhapsody Designer for Systems Engineers edition [IBM09] would be the best suited option for the development of ORCS.
2.7 Goal of the Master Thesis With this theoretical background explained in the previous sections, the goal of master thesis is de ned in this section. The main goal of this thesis is to provide standard notations for problem frames using SysML and to improve the requirement modeling process in SysML using the problem frames. Also a systematic methodological approach for the software development using SysML is provided. So in this thesis work, we try to combine problem frames and SysML and to integrate them with a standard software development process such as DePES. The main focus is given to the creation of a homogeneous model of software which will contain all artifacts created in every phase of a software development along with the interrelation between them. Software developed using such model would satisfy all the stated requirements and would be robust with minimal defects.
18
Chapter 3 Phase 1: Requirements Analysis A well de ned problem is half solved. Lou Cohen
The rst step of any software development process is to perform requirements analysis. Requirements need to be gathered and analyzed systematically. Requirements analysis is not only limited to just gathering of requirements but also extended to acquire domain knowledge (facts and assumptions) about the participating domains, relationships and dependencies between the requirements and classi cations of requirements based on the underlying sub-problems.
In this chapter we focus on how the requirements analysis
phase is handled in DePES using the rst 4 steps of the process. Integration of SysML and problem frames for doing e cient requirements analysis is also described. As a proof of concept, the proposed approach would be applied to the development of ORCS.
3.1 Step 1: Describe system in use Development of our proposed approach is started with the rst step of DePES. More details about the DePES steps could be found in [Hei08a].
1 is built in order to solve a problem in the outside world. For example, a
A machine
library management system is developed in order to solve a problem of maintaining the information about books in a library such as classi cation of books, who has borrowed the book, what is the return data, information about the members etc. So before considering What is a problem?, we should rst start with a question Where is the problem?. The information about the context of a problem provides essential information about where the particular problem is located. Gathering of context or external environment information is accomplished in many traditional disciplines like civil and mechanical engineering.
But in software engineering, the importance to the context information
is not yet given up to the required level.
This could result in the failure of a system.
For example, the failure of Arian 5 [Lio96]. The example proved that while developing a software, equal importance must be given to the context of a problem.
A software
engineer should have good knowledge about the environment where the software is going to integrate. He/she should clearly understand what changes does the proposed software make to the external environment. So the software development process should always start with the description of context. The context of a problem can be e ciently described using a context diagram [Jac01, ch. 2]. Context diagram must be provided by the customer/ domain expert. It should describe the domains/components of the existing system and the connections between them. The purpose of each domain should be described. The domain knowledge should be
1
The machine is the system to be built.
19
Chapter 3 Phase 1: Requirements Analysis explained in terms of facts and assumptions. Finally the customer/ domain expert states the problem or short comings of the existing system and propose possible alternatives in order to overcome the problem. In this rst step, the description about the software which we want to build will not at all considered. Only the existing system is discussed.
3.1.1 ALLFlight Context diagram The context diagram of the existing ALLFlight system is shown in Figure 3.1. Figure 3.1 gives insight into the existing components of ALLFlight system. As stated earlier in Section 2.5, the main components of ALLFlight are termed as HAP and their sub-components as AP. The arrow lines connecting dierent APs show the interfaces between dierent AP and the labels on the arrow line describes the phenomena means the actions/events/operations that are taking place between the APs using the corresponding interfaces. The complete domain knowledge of ALLFlight project is not covered in this thesis report. Only the important facts and assumptions are stated in Table 3.1 which would be required for further development. The complete information about the ALLFlight project could be found in [Ham08]. Capturing the domain knowledge is not a one time task. It is an iterative process. The assumptions must be carefully handled. Domain knowledge
Type
EC is the on board computer of FHS and APs namely HR, HC and TF are
Fact 1
implemented on it EC uses big endian
2 [Ver96] character encoding format
SCC is the on board computer of FHS and HAP AS and AP VC are imple-
Fact 2 Fact 3
mented on it ECC is the on board computer of FHS and HAP TG implemented on it SCC and ECC use little endian
3 [Ver96] character encoding format
Fact 4 Fact 5
AS is responsible for gathering sensor information and obstacle detection
Fact 6
HR is responsible for gathering helicopter's control signal such as velocity,
Fact 7
stick position etc. Table 3.1: Summary of Domain Knowledge after Step 1
The existing system lacks in some important functionalities and they are listed as short-
comings as follows:
•
SC1: communication monitoring between the HAP/APs is required
•
SC2: overall behavior model of the system is needed
•
SC3: calculation of regimes, mission states, sensor support etc. is required for the e cient decision making system
2 3
•
SC4: forwarding of the data between the HAP/APs is required
•
SC5: logging of the data is required
The most signi cant value in the sequence is stored at the lowest storage address The least signi cant value in the sequence is stored at the lowest storage address
20
Trajektoriengenerierung HAP 2 / AP 1-3 On ECC
21
FHS LASER RADAR IR TV
FHS BoardrechnerSensordaten (incl. Bodenkontaktschalter)
Geländedatenbank
Hubschrauberregelung Modelfolge Kommandomodelle HAP 3 / AP 1-2 On EC Visual Cues HAP 4 / AP 1 On SCC
FHS Aktuatoren
Führungsgrößen
Trajektorien
DVE Realisierung Im Simulator HAP 4 / AP 3
Regime Recognition HAP 5 / AP 2
Envelope Protection HAP 4 / AP 3
Flugeigenschaften Operationelle Aspekte HAP 5 / AP 1,4
Geländedaten (a-priori Wissen) & Generierung einer Geländedatenbank auf Basis aufgezeichneter visueller Sensordaten
Haptic Cues HAP 4 / AP 2 On EC
control augmentation
visual cues
Figure 3.1: Context diagram of ALLFlight Project
Sensordaten vom Experimentalsystem
Trajektorienfolge Intuitive Control Strategy HAP 3 / AP 3-4 On EC
FHS BoardrechnerDatenaufzeichnung
Daten für die Aufzeichnung im Experimentalsystem
Außen- situation HAP 1 / AP 1-4 On SCC
Pilot
„Delta Gelände“ im Vergleich zur Geländedatenbank
Dateneingabe Display Funktionstasten
haptic cues
Chapter 3 Phase 1: Requirements Analysis
Chapter 3 Phase 1: Requirements Analysis The addition of above mentioned functionalities would de nitely improve the pilot assistance capabilities of the existing system. These functionalities would help in increasing situational awareness and tracking of all parameters. Now the question comes "How can we achieve these functionalities?". All possible ways for implementing these functionalities are thoroughly discussed and come with the following development alternatives.
•
ALT1: add the required functionalities (stated above as shortcomings) to the existing HAPs
•
ALT2: add a new module to the existing system which will execute the required functionalities
The validation conditions of Step 1 are veri ed as follows:
•
All domains and phenomena in the context diagram are described.
•
Shortcomings are stated using elements of the domain knowledge description. For example, SC1 and SC4 cover all HAPs
•
Possible development alternatives consider at least one of the shortcomings. For example, Both ALT1 and ALT2 consider all SCs
3.2 Step 2: Describe system to be built After gathering the knowledge of participating domains, the next step of DePES is to describe a system to be built that means a machine. The expected system is described using the system mission statements. These system mission statements correspond to the shortcomings of the existing system stated by the domain experts in the rst step. The available development alternatives are veri ed against the system mission statements in terms of time, cost, eorts and e ciency and the appropriate one is selected. Now the context diagram drawn in Step 1 is modi ed. The machine domain is added to the diagram which represents the system which we want to develop. The domains and the interfaces are changed, added, omitted or re ned as per the need of the mission statements and the selected development alternative. This context diagram represents the scenario after integrating the desired features within the existing system. The context diagram provides clear distinction between the machine domain and the problem domains. The context diagram includes connection (interface) between machine and problem domains. It also shows the phenomena that are shared between the domains using the interface. As of now there is no standard template available for the context diagram. So as a rst step of creation of a homogeneous model, we propose to draw a context diagram using a block de nition diagram of SysML. The context diagram would represent a very high level structure of a system along with its environment. The participating machine and other problem domains could be drawn using a block. The type of each domain such as lexical or causal or biddable could be represented using prede ned stereotypes.
Stereotypes provide great exibility while designing a model. The connection between these domains could be shown using association. Again with the help of stereotype, we can specify the type of association. An association between the domains represents the interface between them and its label abstracts the phenomena shared between the domains using that interface. The domain information provided by the domain expert can be added into the description eld of a block. Any condition or limitation can be modeled using a constraint. If required, the decomposition of the domains can be represented by adding internal block diagram to the respected domain block.
22
Chapter 3 Phase 1: Requirements Analysis After describing the context of the machine, the customer/ end user de nes his/her expected requirements about the machine in a natural language. This step is very important as it sets the base for further development. Requirements are the desired characteristics of a system. A clear understanding between the customer and the developer is very essential. The developer must check whether the given requirements are consistent with the domain knowledge or not. Also he/she needs to verify whether the given requirements are implementable or not. At this step, we propose to use SysML requirements diagram in order to handle requirements analysis more e ciently. The requirements diagram helps the developer to visually describe his/her understanding about the requirements stated by the customer, interrelation between them and their plausibility regarding implementation. Because of the visual modeling of requirements, a customer can also easily verify developer's understanding about the requirements. The requirements diagram provides a check for plausibility and any misinterpretation about the requirements at an early stage of software development which results into less number of defects. The requirements are classi ed based on whether they are need to have or nice to have and then a priority is assigned to them. Now we perform the context description and requirements analysis of ORCS in the following subsections.
3.2.1 System Mission Statement In order to overcome the shortcomings of existing ALLFlight and to improve the existing system, the system mission statements are stated.
•
SM1: The system should monitor the communication between the HAP/APs
•
SM2: The system should model the overall behavior of the helicopter
•
SM3:
The system should implement a decision making system based on the
regimes, mission states, TF states etc.
•
SM4: The system should be able to pass the data between the HAP/APs
•
SM5: The system should log the data
The available development alternatives are checked against the mission statements for their feasibility. The pros and cons of the each alternative are described as follows:
•
ALT1: added complexity, di cult to maintain, overhead for HAPs developer
•
ALT2: eective distribution of responsibilities, independent modules are easy for maintenance
After the discussion with domain experts, the second development alternative is selected. A separate module would be developed which will accomplish the desired features stated in system mission statements.
The module is named as Online ReCon guration and
Supervision' (ORCS). ORCS is a sub-component of ALLFlight de ned under HAP 5/AP 3 (refer Figure 2.12). Now we start describing the context of ALLFlight project after the inclusion of ORCS.
23
Chapter 3 Phase 1: Requirements Analysis
3.2.2 ORCS Context diagram The context diagram of ORCS using a block de nition diagram is shown in Figure 3.2.
ORCS
is the machine that is the software that we want to build in order to control
other components of the ALLFlight system. a stereotype by
ORCS
Machine.
ORCS
is represented using a block with
All other components of ALLFlight which would be controlled
are implemented either on the Experimental Computer (EC) or Experimental
Co-Computer or Sensor Co-Computer (SCC) of the Flying Helicopter Simulator (FHS). As shown in Figure 3.1,
ORCS
interacts with dierent APs of ALLFlight project such
as AuÿenSituation (AS) (HAP 1/AP 1_4)
4 , Trajektoriengenerierung (HAP 2/AP 1_3)
5 (TG), Trajektorienfolge (HAP 3/AP 3_4) 6 (TF),Hubschrauberregelung (HAP 3/AP 7 (HR), Haptic Cues (HAP 4/AP 2) (HC) and Visual Cues (HAP 4/AP 1) (VC). 1_2)
ORCS actually works through EC, ECC and SCC. The ORCS would ECC of the FHS. AS and VC are implemented on SCC. HR, HC implemented on EC. TG is implemented on ECC. In Figure 3.2, a high level
With these HAP's,
be implemented on and TF are
abstraction of the expected system is shown.
Figure 3.2: Context Diagram of ORCS
4
External Environment Trajectory Generation 6 Trajectory Following 7 Helicopter Controller 5
24
Chapter 3 Phase 1: Requirements Analysis The interfaces are de ned as follows:
A B C D E
=
F G H
=
= = = =
= =
Since the
{sendOrcsEcUdpOutput,
sendEcOrcsUdpInput} sendSccOrcsUdpInput} {sendOrcsEccUdpOutput, sendEccOrcsUdpInput} {loadInitFile, ndInitFileParameters} {receiveEcOrcsUdpInput, receiveEccOrcsUdpInput, receiveSccOrcsUdpInput, parseInput, storeInput, lterInput, generateOutput, parseOutput, requestRREvent, checkInputData} {writeLogFile} {setCommunicationParameters} {CommunicationParameters} {sendOrcsSccUdpOutput,
EC, ECC
and
SCC
are computers that means electronic devices, they are con-
sidered as causal domains and represented using a block with a stereotype
ECC
and
SCC
Causal. EC,
are the part of an external environment with which ORCS will be inte-
grated. The communication between the machine (ORCS) and the problem world (EC, ECC and SCC) is via UDP communication. This is represented by the interfaces A, B and C respectively. We assume that EC, ECC and SCC know the IP address and the receiver port number of ORCS. EC uses big endian coding format while SCC and ECC use little endian coding format.
EC sends the UDP data packet to ORCS containing data of HR, HC and TF via interface A using the phenomenon sendEcOrcsUdpInput. Every UDP data packet contains the sender's ID for the identi cation.
The main objective of ORCS is to build a decision
making system with the help of the received data. Automatic Regime Recognition (RR) (details in Subsection 4.5.1) is a part the decision making system of ORCS. The Regime Recognition is modeled based on the data sent by HR using the phenomena and
requestRREvent
of the interface
E.
lterInput
The HR data includes ight velocity, status of
8 position of the activated stick (either side or center
the active stick and coolie hat
stick). The other parts of the decision making system are similarly modeled based on the data received from dierent HAPs. However, this is currently in the research phase. So as of now the
ORCS
sends back only the current and expected regime (output of RR)
along with some more information required by the HAPs to EC using the phenomenon
sendOrcsEcUdpOutput
of the interface
corresponding HAPs. The functioning
A. EC then of EC is out
in turn distributes the data to the of the scope of ORCS development.
In the following chapters, even though it is mentioned as send by HAP it actually means send by
EC
or
ECC
or
SCC
on behalf of a corresponding HAP. This terminology
is used for the sake of the classi cation of input data according to HAP. The same is applied for send to HAP. A similar ow of action takes place between data packets from interface
B.
SCC
ORCS
and
SCC
where
ORCS
receives UDP
containing sensor and visual information from AS and VC via
The sensor information includes the total number of active sensors and
name, type, quality, operating status and timestamps of each active sensor. Based on this information ORCS determines the level of sensor support and informs other HAP. ORCS also uses the sensor information in order to determine the mission state (part of decision making system of ORCS). However, it is still in the research phase and hence can not be implemented.
8
Coolie hat is a joystick like control button on the helicopter's side/center stick. It is used by a pilot in order to neutralized the stick forces
25
Chapter 3 Phase 1: Requirements Analysis Phenomena or domain
Domain knowledge
Type
System Administrator
would set the correct communication param-
Assumption 1
eters inside
sendEcOrcsUdpInput
EC knows ORCS
Init File IP address and port number of
Assumption 2
Table 3.2: Summary of Domain Knowledge after Step 2
TG would be implemented on ECC. Since it is still in the research phase, we just represent the future interface between ORCS and ECC using the interface and TF are also in the research phase.
C.
Similarly HC, VC
Hence we will not go into the details of these
APs. Other than these causal domains, there are three more domains added in Figure 3.2
Init File, LogFiles
namely
and
HAP Data Container. All are lexical and design domains Lexical and Designed respectively. As the name
represented using a block and stereotypes suggests, between
Init File domain represents le that is used to initialize the UDP communication ORCS and EC, ECC, SCC. The le contains hand coded parameters such as
sender's identi ers and port numbers. contents of initialization le.
Whenever ORCS is started it rst loads the
This is represented by the phenomenon
loadInitFile.
In
Init File sends back hand coded parameters to ORCS as shown ndInitFileParameters. These phenomena are represented using the
response to this request, by the phenomenon interface
D.
HAP Data Container from EC, ECC and SCC The
domain represents a data holder for the data which is coming
ORCS to EC, ECC and SCC using EC, ECC and SCC is received by ORCS using phenomena receiveEcOrcsUdpInput, receiveEccOrcsUdpInputand receiveSccOrcsUdpInput. It is then classi ed according to a HAP and stored in the HAP Data Container using the phenomena parseInput and storeInput via the interface E. The structure of the to
ORCS
and going from
UDP communication. The incoming data from
incoming and outgoing UDP data packet is pre-de ned. ORCS extracted the output data
HAP Data Container using the phenomenon parseOutput via E .It sends back output data to EC, ECC and SCC using the phenomena sendOrcsEcUdpOutput, sendOrcsEccUdpOutput and sendOrcsSccUdpOutput of the interface A, B and C respectively.
of dierent HAPs from the the interface
LogFiles is the lexical domain need to be designed in order to maintain log of incoming ORCS writes data to these les using phenomenon writeLogFile of the interface F.
The
data, outgoing data, warnings and error messages. a
Finally the context diagram contains one biddable domain named as
trator.
System Adminis-
This domain represents a person who is responsible for the overall maintenance
of the system. We assume that the
System Administrator
knows the correct information
(port number, identi er) required to establish an UDP communication path between
ORCS
Init File is on ECC. The System Administrator sets communication parameters in the Init File with the help of editing tool available on ECC. This is represented using the phenomenon setCommunicationParameters via the interface G between the domains System Administrator and ECC. These parameters are later used by ORCS. and other domains. The
As stated earlier, capturing the domain knowledge is an iterative process. The domain knowledge added after Step 2 is summarized as shown in Table 3.2.
26
Chapter 3 Phase 1: Requirements Analysis Name
Requirements
Req.comm.1
The Init File on ECC should be created and the communication parameters required to establish UDP communication between the ALLFlight components should be set. This should be done by the system administrator
Req.comm.2
The proposed system should always be ready to accept all incoming UDP data packets
Req.comm.3
The proposed system should only process the incoming UDP data packet from the known sender HAPs
Req.comm.4
The proposed system should always able to send output data to the known sender HAPs Table 3.3: Communication Requirements of ORCS
Name
Requirements
Req.3.1_2.1
In order to create a helicopter's current situational model, helicopter's current control data (e.g., velocity, stick position etc.) need to be gathered
Req.3.1_2.2
Based on the helicopter's current data model, a possible switching from current to next regime needs to be calculated.
Req.3.1_2.3
The calculated regime switching must be conveyed back to the helicopter's pilot Table 3.4: ORCS - HR Requirements
3.2.3 ORCS Requirements Let us start with the requirements analysis of ORCS. As described in Section 2.5, ORCS interacts with dierent HAPs. From the domain knowledge gathered in Step 1 and 2, we know that all HAPs are implemented either on mented on
ECC.
EC, ECC
or
SCC
and
ORCS
is imple-
So the initial requirement would be to setup the communication path
between HAP and ORCS that means between EC, SCC and ECC. The communication requirements are shown in Table 3.3 After the basic communication requirements, the requirements of each HAP are analyzed. HAP experts describe the desired characteristics in terms of input, data processing and output requirements of ORCS and HAP. The requirements are consolidated from the domain knowledge described in Section 3.1 and meetings with the corresponding HAP expert. The requirements of ORCS with respect to HAP HR are shown in Table 3.4. Similarly other HAPs, logging and decision making requirements are gathered. All ORCS R
requirements are modeled within IBM Rational Rhapsody using requirements diagram. However, in the following sections only HR requirements are analyzed as an example.
3.2.4 ORCS Requirements diagram After receiving the requirements from the domain expert, now a developer can visually model the requirements using a requirements diagram.
A developer can add relation-
ships between the requirements as per his/her understanding which could be then veri-
27
Chapter 3 Phase 1: Requirements Analysis ed by the customer. Figure 3.3 represents requirements of ORCS with respect to HAP Hubschrauber-(Regelung) (HR). Requirements diagram provides dierent types of relations e.g., trace, derived, satisfy etc. in order to model relation between the requirements and between the requirements and other model elements.
Figure 3.3: Requirements Diagram of ORCS with respect to HR
Figure 3.3 represents the requirements diagram showing the requirements of ORCS with respect to HR. Figure 3.3 represents requirements stated in Table 3.4 more systematically. It shows how the given 3 requirements are sequentially dependent on each other. Also it models their relationship with the elements which implement them.
UDPCommunicationBlock
satis es the requirements
Req.3.1_2.1
and
For example,
Req.3.1_2.3
(refer
Section 5.1.1). This helps in tracing the requirements. Further the test cases could be added to the diagram which would verify the requirements. The validation conditions of Step 2 are veri ed as follows:
•
The system mission statement addresses the shortcomings. addresses
•
For example,
SC1
SM1
The phenomena and the domains of the context diagram are emphasized in the requirements and in the domain knowledge
•
All given and designed domains are referenced in the requirements and the domain knowledge. For example,
•
EC
is referenced in
No contradictions were found in
Req.3.1_2.1
and
Req.3.1_2.3
D∧R
The requirements diagram visually provides an insight into the given requirements, their dependencies, their role and their relation with software components. While drawing the requirements diagram for HAP AS, we found that there is a requirement which mentions that ORCS provides current and next mission states to AS. But we have not found any
28
Chapter 3 Phase 1: Requirements Analysis requirement stating generation of such mission states by ORCS. This clearly shows us sign of a missing requirement. When both the customer and the developer agree on the requirements diagram, only then the developer should start further development.
3.3 Step 3: Decompose problem After gathering the requirements, the next task would be to classify these requirements. Each requirement represents a sub-problem that is a small part of a big problem.
As
already stated, 2 big problems can look altogether dierent but they may share some common sub-problems. So we need to analyze these sub-problems separately in which we might come across an already solved problem and thus can reuse our knowledge. For getting well de ned sub-problems, there are many methods available. For example, top-down decomposition based on function hierarchy or use-case decomposition based on object orientation. In this thesis work, knowledge based decomposition using projection is used in which the knowledge of problem classes and their solutions are used for decomposition. The analysis of the requirements can be eectively done with the help of problem frames which help in assigning a problem class to a sub-problem. Problem frames are nothing but the templates representing commonly occurring problems. They consist of a machine and problem domains which are participating in a requirement. By comparing nature of a given requirement and participating domains, the corresponding problem frame can be selected in which a given sub-problem can perfectly t. Also one of the main objectives of this thesis work is to provide standard notations to the problem frames using SysML. The Internal Block diagram and stereotypes of SysML R
are used to represent frame diagrams within IBM Rational Rhapsody tool. As already mentioned, model building, transformation and data-based control problem frames are important for the development of ORCS. So in this section, only these problem frames are considered. The frame diagrams proposed by M. Jackson for model building, transformation and data-based control problem frame are shown in Section 2.3. Figures 3.4, 3.5 and 3.6 show the frame diagrams for the problem frame model building, transformation and data-based control respectively using SysML.
Figure 3.4: Model Building Problem Frame using SysML notations
29
Chapter 3 Phase 1: Requirements Analysis The participating domains (Modeling
Machine, Real World
and
Model)
shown in the orig-
inal frame diagram of model building problem frame (see Figure 2.8) are shown with the help of blocks in Figure 3.4. The type of each domain such as causal, lexical, designed and machine is modeled using stereotypes.
The connection between the participating
domains that is the interface is modeled using binding connectors.
The ow items of
the binding connectors are used to represent the phenomena (RW!C1 and requirement oval (Modeling
Real World)
MM!E2).
The
is represented using the requirement element of
the requirements diagram. The textual description of the requirement can be added into the description tab of the requirement. A unique identi er (MRW1) can also be assigned to the requirement for the future reference.
Figure 3.5: Transformation Problem Frame using SysML notations
Similarly the mapping between the original frame diagram of transformation and databased control problem frame (see Figures 2.9 and 2.10) and using internal block diagram of SysML (see Figures 3.5 and 3.6) can be explained. Also all other problems frames like required behavior, commanded behavior, simple workpieces etc. can be modeled using standard notation of SysML.
3.3.1 Instantiated problem frames for ORCS After going through the requirements of all HAPs, common patterns are found between these requirements.
For every HAP, ORCS is receiving some data related to external
environment. ORCS is storing this data and then processing it based on some prede ned criteria. The output data after the processing is then sent back to the respected HAP. The HAP then acted based on the received output. We compare each requirement with the description of each problem frame. The requirements of every HAP fall into 3 main categories.
The requirement describing receiving and storing of external environment
data covers the problem of model building. The requirement describing the processing of input data and generating output data covers the problem of transformation.
The
requirement describing the controlled behavior based on output data covers the problem of data-based control. This shows that we can classify the requirements under a common
30
Chapter 3 Phase 1: Requirements Analysis
Figure 3.6: Data-based Control Problem Frame using SysML notations
class and could be handled in a similar way. This facilitates the reuse of already proven knowledge. Knowledge reuse has 2 advantages. Firstly is it saves time and secondly since it is already proven there are less chances of defects. Now we instantiate the frame diagrams with appropriate domains and requirements of ORCS and HR (refer Subsection 3.2.4).
The domains (blocks) created in the context
diagram of ORCS shown in Figure 3.2 are reutilized in order to establish relation between requirements and domains.
We also apply the principle of domain decomposition and
phenomena re nement whenever required [Jac01, ch 3]. In the rst requirement
Req.3.1_2.1,
ORCS is trying to get real world information such
as opponent wind velocity, status of active stick and coolie hat position of side and center stick from the HR and storing it for the further processing. So this scenario can be tted into model building problem frame. The instantiated model building problem frame is depicted in Figure 3.7. We use the following decomposition operators on the context diagram shown in Figure 3.2 in order to obtain the instantiated model building problem frame depicted in Figure 3.7.
•
We divide the lexical domain
Data.
•
The domain
OtherData represents the data from the HAPs other than the HR
We leave out the domains
ministrator
OtherData, LogFiles, SCC, ECC, Init File
B, C, D, F, G
•
We leave out the interface
•
We leave out the phenomena
•
We re ne the phenomenon
HRInput
•
HAP Container Data into the HRInputData and Other-
and
System Ad-
H
sendOrcsEcUdpOutput sendEcOrcsUdpInput
We leave out all other phenomena of the interface
31
and
of the interface
of the interface
E
except
A
A
to the
send-
receiveEcOrcsUdpInput,
Chapter 3 Phase 1: Requirements Analysis
Figure 3.7: Instantiated Model Building Problem Frame for the requirement
parseInput
and
storeInput
Req.3.1_2.1
phenomena
•
We re ne the phenomenon
•
We re ne the phenomena
receiveEcOrcsUdpInput
to
receiveHRInput
parseInput and storeInput of the interface E to parseFlightVelocity, parseActiveStickStatus, parseSidestickPosition, parseCenterstickPosition, parseCosMode, storeFlightVelocity, storeActiveStickStatus, storeSidestickPosition,storeCenterstickPosition and storeCosMode respectively
Its interfaces are de ned as follows:
C1 E2
C3 Y4
= =
= =
{sendHRInput}
{receiveHRInput, parseFlightVelocity, parseActiveStickStatus, SidestickPosition, parseCenterstickPosition, parseCosMode, FlightVelocity, storeActiveStickStatus, storeSidestickPosition, CenterstickPosition, storeCosMode} {Helicopter's control signals} {HRInputdata}
parsestorestore-
From the context diagram description (refer Subsection 3.2.2), HAP HR is implemented
EC is the real world for ORCS. So in Figure 3.7, EC generates the causal event sendHRInput which is represented by the phenomenon C1. These causal events are corresponding to the actual helicopter's control signal represented by the phenomenon C3. The ORCS represents the modeling machine which monitors the causal events sent by the EC using C1. The Modeling Real World requirement is instantiated by Req.3.1_2.1. ORCS receives UDP data packets from EC. It translates (parses) the incoming causal events and stores them into the lexical domain HRInputData which represents the model. This is represented by the phenomena receiveHRInput, parseFlightVelocity, parseActiveStickStatus, parseSidestickPosition, parseCenterstickPosition, parseCosMode, storeFlightVelocity, storeActiveStickStatus, storeSidestickPosition, storeCenterstickPosition and storeCosMode
on the Experimental Computer of FHS. So The
Real World
is instantiated by
EC.
The
respectively.
32
Chapter 3 Phase 1: Requirements Analysis The second requirement of HR (Req.3.1_2.2) states that the current and next regime are generated using the incoming data. The current and the next regimes are generated using the Regime Recognition State chart based on the input data received from the HR and stores it as an output data. This is clearly a case of data transformation from one lexical domain to the other. This scenario can therefore be modeled using the transformation problem frame. The instantiated transformation problem frame is depicted in Figure 3.8.
Figure 3.8: Instantiated Transformation Problem Frame for the requirement
Req.3.1_2.2
We use the following decomposition operators on the context diagram shown in Figure 3.2 in order to obtain the instantiated transformation problem frame depicted in Figure 3.8.
•
HAP Container Data into the HRInputData, HROutputData and OtherData. The domain OtherData represents the data from the HAPs We divide the lexical domain other than the HR.
•
We leave out the domains
Administrator
OtherData, LogFiles, SCC, ECC, EC, Init File A, B, C, D, G, F
•
We leave out the interface
•
We leave out all phenomena of the interface and
•
requestRREvent generateOutput generateNextRegime
We re ne the phenomenon
Regime
and
and
E
and
System
H except
generateOutput, lterInput
of the interface
E
to
generateCurrent-
Its interfaces are de ned as follows:
Y1 Y2
=
Y3 Y4
=
=
=
{FlightVelocity,
{ lterInput,
Regime} {HRData} {HROutput}
ActiveStickStatus, SideStickPosition, CenterstickPosition} requestRREvent, generateCurrentRegime, generateNext-
In Figure 3.8, the input and output data is instantiated by the lexical domains
33
HRIn-
Chapter 3 Phase 1: Requirements Analysis putData
HROutputData respectively. The IO Relation requirement is instantiated by the requirement Req.3.1_2.2. The ORCS represents the transform machine. The ORCS reads the input data from the HRInputData domain. This is represented by the interface Y1 and the corresponding phenomena FlightVelocity, ActiveStickStatus, SidestickPosition and CenterstickPosition. The ORCS determines the current and the next regime based and
on the parameters ight velocity and the stick position.
The correspondence between
the input and output is implemented using a Regime switching state chart. The regime is a 4 digit value and it is coded based on the position of helicopter's 4 axes namely pitch, roll, yaw and collective. The regime recognition is represented by the phenomena
lterInput and requestRREvent. The ORCS then generates and stores the regime values into the HROuputData. This is represented by the interface Y2 and the corresponding phenomena generateCurrentRegime and generateNextRegime. In the last requirement of the HR (Req.3.1_2.3), an UDP data packet containing both the current and next regimes is generated and send back to the HR which in turn performs the regime switching. In this case we are trying to control the state of the causal domain
EC (to be precise state of HR implemented on EC) by the data stored in a lexical domain HROutputData. This scenario can be modeled using a data-based control problem frame. The instantiated data-based control problem frame is depicted in Figure 3.9.
Figure 3.9: Instantiated Data-based Control Problem Frame for the requirement
Req.3.1_2.3
We use the following decomposition operators on the context diagram shown in Figure 3.2 in order to obtain instantiated data-based control problem frame depicted in Figure 3.9.
•
HAP Container Data into the HROutputData and Other Data represents the data from the HAPs other than
We divide the lexical domain
OtherData.
The domain
HR.
34
Chapter 3 Phase 1: Requirements Analysis
•
We leave out the domains
Administrator
OtherData, LogFiles, SCC, ECC, Init File
B, C, D, F, G
•
We leave out the interface
•
We leave out the phenomenon
•
We re ne the phenomenon
HROutput
and
System
H
sendEcOrcsUdpInput
sendOrcsEcUdpOutput
•
We leave out all other phenomena of the interface
•
We re ne the phenomenon
parseOutput
and
of the interface
A
of the interface
A
to the
send-
E except parseOutput phenomenon
of the interface
E
to
parseHROutputData
Its interfaces are de ned as follows:
C1 Y2 C3
= = =
{sendHROutput}
{parseHROutputData} {RegimeSwitching}
HROutputData which holds the data that is used to control the external world that is EC. The HROutputData contains the current and the next regimes determined by the ORCS. ORCS extracts the data from the HROutputData and creates an UDP data packet from it. This is represented by the interface Y2 and its phenomenon parseHROutputData. ORCS then sends both the current and next regimes to the EC using UDP data communication. EC is the the Controlled Domain. This is represented using a interface C1 and its phenomenon sendHROutput.
The lexical domain
Database
is instantiated by
The systematic requirements analysis helps in identifying relationships between the subproblems.
Such relationships can be expressed using a context-free grammar called
Backus-Naur Form (BNF) [W.59].
In general, sub-problem relations in ORCS can be
expressed as follows:
::= || || ::= ReceiveHRData ::= SendHRData Likewise the requirements of other HAPs, communication and logging requirements of ORCS can be instantiated using an appropriate problem frame and could be analyzed eectively. The requirement System administrator sets the communication parameter in init le can be handled using a simple workpieces problem frame. Other data processing requirements such as mission states calculation and checking sensor support status can be handled using the transformation problem frame as shown above. The description of all requirements and their corresponding problem frames is not included in this report. The requirements which get tted into the same problem frame are handled in a similar way. Also the facts and assumptions captured during the context diagram description must be correctly considered. If we can not model certain requirements using the existing problem frames, then it gives us chance at a very early stage of the development to identify the missing requirements or possibility of a new problem frame. In ORCS development, all the captured requirements get tted into already existing problem frames. So no new problem frames are discovered. The validation conditions of Step 3 are satis ed as follows:
•
The problem diagrams were derived from the context diagram by applying the introduced operators
•
Requirements of Step 2 are treated in at least one sub-problem
35
Chapter 3 Phase 1: Requirements Analysis Name
Speci cations
Spec.3.1_2.1a
ORCS receives (receiveEcOrcsUdpInput) an UDP data packet containing information from EC about the velocity of the opponent wind, status of active stick and coolie hat position of side or center stick depending on the status of active stick.
Spec.3.1_2.1b
ORCS parses (parseFlightVelocity, ...)
the incoming UDP packet
from HR and stores (storeFlightVelocity, ...) the parsed data. Spec.3.1_2.2
ORCS
performs
Regime
switching
using
the
Regime
Recogni-
tion State chart based ( lterInputData, requestRREvent, generateHROutputData) on the input data received from the HR. Spec.3.1_2.3a
ORCS creates output UDP data packet from the stored Regime values (parseHROutputData).
Spec.3.1_2.3b
ORCS send back the current and next regime determined by the state chart of regime recognition to EC (sendHROutput). Table 3.5: ORCS - HR Speci cations
3.4 Step 4: Derive a machine behavior speci cation for each sub problem While de ning the problem context, the problem and the sub-problems, user/customer/developer's point of view is taken into account. However, for the correctness of further development, it is necessary to consider now machine's (software to be built) point of view. For this, the machine speci cations need to be derived from the already gathered domain knowledge (facts and assumptions) and the customer stated requirements. A speci cation means implementable requirement. A machine speci cation speci es How should the machine act, so that the system ful lls the requirement?. The speci cations state the responsibility of the machine. The speci cations give insight to the implementation. The correct speci cations are key to the correct implementation. Basically a speci cation decides whether the given requirement is feasible to implement or not based on the facts and assumptions of the domain knowledge. Thus if each element of the given requirement (R) is correct with respect to facts (F) and plausible with respect to assumptions (A) only then a machine can be constructed based on the speci cation (S) which will eventually satisfy the given requirements. This can be formulated as
F ∧ A ∧ S => R.
3.4.1 ORCS Speci cations From the available domain knowledge and requirements from Subsections 3.2.2 and 3.2.4, the derived speci cations of ORCS are summarized in Table 3.5.
3.4.2 ORCS Speci cations Diagram Similar to the modeling of requirements using a requirements diagram, we propose here to also model the speci cations using a requirements diagram. The speci cation diagram describing the speci cations of
ORCS
is shown Figure 3.10.
It contains the same speci cations shown in Table 3.5. However as stated earlier, graphical visualization increases understandability. Speci cations are represented using a Re-
36
Chapter 3 Phase 1: Requirements Analysis
Figure 3.10: Speci cations Diagram of ORCS with respect to HR
quirement with a stereotype Speci cation. Speci cations have the same ID as that of the corresponding requirement. Only the pre x req is replaced with spec. The su xes
a, b etc. are appended in case multiple speci cations are derived from one requirement. The use of same IDs increases traceability. Like a requirements diagram, software components satisfying the speci cations could be added later. The relationships between the speci cations are kept same as that of relationships between the requirements.
3.4.3 ORCS Sequence Diagram After stating the speci cations, a sequence diagram is drawn at least one per requirement in order to represent the ow of actions and control between the domains.
The
correspondence between context diagram phenomena, problem diagram phenomena and messages in sequence diagram veri es whether the given requirement is implantable or not. The sequence diagram also provides outline for the testing in Step 12. The sequence diagram for the requirement
Req.3.1_2.1
is shown in Figure 3.11.
The sequence diagram for the requirement
Req.3.1_2.2
is shown in Figure 3.12.
Figures 3.11 and 3.12 show the sequence of interactions taking place between the participating domains.
They show the sequence and the direction of messages from one
domain to the other. Also when compared the messages in the sequence diagram with the phenomena de ned in the previous section, they get mapped correctly. This mapping is shown in Table 6.1 in Section 6.3. These messages give an insight into the further implementation details. Likewise sequence diagrams for other requirements can be drawn and veri ed.
37
Chapter 3 Phase 1: Requirements Analysis
Figure 3.11: Sequence diagram for the requirement
Req.3.1_2.1
Figure 3.12: Sequence diagram for the requirement
Req.3.1_2.2
38
Chapter 3 Phase 1: Requirements Analysis The validation conditions of Step 4 are satis ed as follows:
•
No contradictions found in
F ∧ A ∧ S.
For example,
F 1 ∧ F 6 ∧ F 8 ∧ F 11 ∧ A2 ∧
S1a ∧ S1b => R1 •
All requirements are captured
•
In the sequence diagrams, exactly the phenomena of the problem diagrams are used and the direction of signals is consistent with the control of the shared phenomena
•
The signals connect domains as connected in the problem diagram
•
The speci cations can be easily derived from the requirements and the domain knowledge expressed as sequence diagrams
39
Chapter 4 Phase 2: Design There are two ways of constructing a software design. One way is to make it so simple that there are obviously no de ciencies. And the other way is to make it so complicated that there are no obvious de ciencies. C.A.R. Hoare
Once a customer and a developer agree upon the stated requirements, the development of the components which are satisfying the requirements is started.
As a rst step
of a component design, a developer starts nding the required components based on the outputs of the requirements analysis phase such as domains, interfaces, phenomena and speci cations.
During the design phase, architecture diagrams are drawn at the
dierent level of abstractions from global to sub-component architecture. At each level, the functionalities are distributed and assigned, phenomena are re ned and we reach one step closer to the implementation.
In DePES, steps 5-9 describe the details of design
phase.
4.1 Step 5: Design global system architecture The global system architecture shows the structure and the interconnection between the components of a system. It contains both software and hardware components of a system. In DePES, it is represented using the composite structure diagram of UML. Since we are using SysML in our proposed approach, we draw the global architecture diagram using an
internal block diagram of SysML which is equivalent to the composite structure diagram of UML. Generally the architecture diagrams contain parts or blocks which represent the components.
Each component has one or more ports.
The components interacts
with each other using the interface that joins the ports. The interfaces are of two types namely: required interface and provided interface. The purpose of each interface must be described brie y. In order to maintain consistency between requirements analysis and design phase, correct mapping must be done between the phenomena and the domains of the analysis phase and the interfaces and the components of the design phase. Such mapping is done based on the following rules.
•
The phenomena controlled by the machine become a part of a required interface of the machine
•
The phenomena controlled by lexical domains in the environment can become a part of a required interface of the machine, if the lexical domain returns a value
•
The phenomena controlled by the environment become a part of a provided interface of the machine
The global system architecture is a very high level architecture.
40
Chapter 4 Phase 2: Design
4.1.1 Global System Architecture of ORCS As stated earlier, in this thesis work the main focus is only on the development of software. We are developing a software component that is ORCS. The overall system architecture with integrated hardware components is not considered here and therefore the global system architecture diagram is not drawn in case of ORCS development.
4.2 Step 6: Derive speci cations for all components of the global system architecture In this step, speci cations of each component from the system architecture diagram are obtained using sequence diagrams.
Sequence diagrams show interactions between the
architectural components and the outer world. In this step, behavior of each component and its sub-components de ned in the architecture of a system in Step 5 are described. The speci cations obtained in this step must re ne the behavior described in Step 4. Like Step 4, a sequence diagram is drawn for each sub-problem covered in Step 3.
4.2.1 Speci cation of Components of ORCS Global System Architecture In case of ORCS development, the global system architecture is not developed as we are developing a software component and not the whole system with software and hardware components. Therefore, the representation of the behavior of ORCS global system architecture's components using the sequence diagram is not performed.
4.3 Step 7: Design a software architecture for all programmable components of the global system architecture In this step, software architecture of all programmable components of the global system architecture are designed for each sub-problem identi ed in Step 3. The software architecture is de ned by Bass et al. [Bas98] as follows:
The software architecture of a program or a computing system is the structure or structures of the system, which comprise of software components, the externally visible properties of those components, and the relationships among them. The architecture of a programmable component (software) consists of components, connectors and interfaces. The components perform the computational part and the connectors describe the interaction between the components. The interfaces de ne the externally visible properties of the components. Interface speci cations can be derived from the sequence diagrams that describe the machine behavior (in Step 4). The explicit design of an architecture for a software makes it more comprehensible. A well designed software can be implemented systematically and can be better maintained. DePES proposes to use a layered architecture such as four variable model (Developed by David Parnas [Par90], extension by Connie Heitmeyer [Bha99]) for representing the software architecture for all components of the global system architecture.
In a lay-
ered architecture, software components are arranged in dierent layers based on whether
41
Chapter 4 Phase 2: Design they are device-dependent or device-independent components. It shows the hierarchical organization of software plus hardware executing software. Like problem frames which are patterns used for the requirements analysis, there exist patterns for software architectures.
A mapping between a problem frame and an
architectural pattern exists. So if we instantiate a particular problem frame for representing a sub-problem, corresponding architectural pattern can be instantiated in order to represent the structure of its components. DePES proposes to develop a separate architecture for each sub-problem identi ed in Step 3. Similar to the global system architecture, DePES uses a composite structure diagram for representing the architecture of the software components.
So as stated before, in
this approach we would use an internal block diagram of SysML for representing the software component architecture. While developing the architecture, either the mapping between the problem frames and architectural patterns can be re-used or an architecture can be developed from the scratch independent of a problem frame. The purpose and responsibilities of the architectural components along with the speci cation of interfaces must be described in detail. The functional responsibilities of each components are based on the underlying common sub-problems. Finally the architectures of each sub-problems are merged into one global software architecture which provides a solution to the main big problem based on the principles stated by Choppy et al. [Cho06]. The components with the same functionalities can be merged into one component in a global software architecture.
4.3.1 Software Components of ORCS As the development of hardware components is not considered in this thesis work, we will not follow the complete four variable layered architecture for representing the architecture of software components of ORCS. ORCS represents only the application layer of the four variable model.
So in this subsection, the application layer software component
representation is handled. ORCS contains only one programmable component named as in DePES, rst we try to decompose
ORCS
ORCS.
Now as proposed
into sub-components for each sub-problem
identi ed in Step 3. The decomposition is based on the object-oriented software architecture. Figure 4.1 shows the architecture of components that satisfy the requirement
Req.3.1_2.1.
The requirement
Req.3.1_2.1 deals with reception of signals from the HAP ORCS.
HR and then their parsing and storing within
ORCS component is decomposed into 4 sub-components Req.3.1_2.1. Each sub-component has its own set of responsisuggests the component MainORCS is the main sub-component of
As shown in Figure 4.1, the original as per the requirement bilities. As the name
ORCS.
It is like a parent component. It is the active component and uses functionalities
provided by the other component in order to ful ll the requirements. It controls the ow of data and control between the other sub-components of
PCommunication
ORCS.
The component
performs the tasks related to the UDP communication of
other HAPs that is with
EC, ECC
and
SCC.
ORCS
UDwith
The responsibility of parsing the input/
output data packets and storing them according to the sender HAP is assigned to the component
DataParser.
Finally the component
HRInputData
represents stored incoming
data from HR which is then used in the further decision making processes. is nothing but the data holder.
HRInputData
Depending on the implementation decisions, it could
be a relational database or a sequential le or just temporary memory holder. Actually
42
Chapter 4 Phase 2: Design
Figure 4.1: Components Architecture for the requirement
Req.3.1_2.1
HRInputData is a sub-component of the component HAPDataContainer. The component HAPDataContainer is divided into sub-components like HRInputData, HROutputData etc. as shown in Figure 4.2. As name suggests, each sub-component of HAPDataContainer represents a separate data holder per HAP. As shown in Figure 4.1, the inter communication between these sub-component is represented using ports (CommPort,
ParserPort, DataPort and NetworkPort) and interfaces (UDPCommIf, ParserIf, DataIf and NetworkIf ). The ports represent the interfaces of the
components with the help which the components communicates with each other and with the external world. They are either required or provided interfaces based on rules de ned in Section 4.1.
UDPCommIf
For example, the component
MainORCS
requires the interface
ORCS and other UDPCommunication
in order to establish an UDP communication path between
UDPCommIf is provided by the component CommPort. The interface UDPCommIf is described using its operations in Figure 4.3. On the other hand, NetworkIf is the required interface of the component UDPCommunication. This interface uses the networking services provided by the underlying operating system. The interface NetworkIf is the external interface of ORCS. Using this interface ORCS interacts with other HAPs which are implemented either on EC or ECC or SCC. The operations are mapped from the speci cation obtained from Step 4. HAPs.
The interface
over the port
Likewise all other interfaces are described by adding operations provided/required by the corresponding component. Figure 4.4 shows the architecture of components that satisfy the requirement The requirement
Req.3.1_2.2
Req.3.1_2.2.
deals with the calculation of regime switching.
The purpose of the components as de ned in the description of
MainORCS, HRInputData and HROutputData is the same Figures 4.1 and 4.2. The component SequenceController
performs operations such as regime calculation, sensor support etc.
which are a part
ORCS's decision making system. Similar to HAPDataContainer, the component SequenceController is also divided into sub-components such as RegimeRecognition, MissionStates etc. based on dierent decision making calculations. The logic for decision
of the
43
Chapter 4 Phase 2: Design
Figure 4.2: Sub-Components Architecture for the component
Figure 4.3: Interface description of
44
HAPDataContainer
UDPCommIf
Chapter 4 Phase 2: Design
Figure 4.4: Components Architecture for the requirement
making is incorporated within
Req.3.1_2.2
SequenceController: RegimeRecognition component using a
state chart. This part is explained in detail in Section 4.5. The architecture diagram for the requirement Figure 4.1.
Req. 3.1_2.3
Req. 3.1_2.3
would be similar to that of
deals with sending of output data from
ORCS
to HR. So for
MainORCS, HRInputData would be replaced
satisfying this requirement, we would require the same components such as
UDPCommunication and DataParser. by the component HROutputData.
Only the component
The components would communicate through the
interfaces shown in Figure 4.1. Because of these similarities, the separate architecture diagram for the requirement
Req. 3.1_2.3
is not shown here.
Similarly the architecture for all requirements of ORCS are drawn.
All architecture
diagrams of the requirements of ORCS are not included in the report. Because of the common patterns in the sub-problems, the same components could be re-utilized. Finally, we merge the sub-problem architectures into a global architecture based on the principles stated by Choppy et al. [Cho06] as follows:
•
Two application layer components that belong to sequential or alternative subproblems should be merged into one component
•
Two application layer components that belong to parallel subproblems, which share some output phenomena should be merged into one component, because the output must be generated in a way so as to satisfy both subproblems
•
If two application layer components that belong to parallel subproblems, which share some input phenomena and which do not share any output phenomena, one can merge the components or keep them separately. In the latter case the common input must be duplicated.
45
Chapter 4 Phase 2: Design
•
Two application layer components that belong to parallel subproblems, which do not share any phenomena should be kept separately.
According to these principles, the global software architecture of
ORCS
is constructed in
Figure 4.5 by merging the sub-problem architectures. The connectors shown from the
DataLogger, SequenceController and DataParser to DataPort of the component HAPDataContainer de ne many to one port multiplicity. This means DataPort and in turn DataIf provided by the component HAPDataContainer is shared with these other components
components.
Figure 4.5: Global Architecture of
ORCS
after the merging of its all sub-components
The validation conditions of Step 7 are satis ed as follows:
•
The subproblem architectures have the same external interfaces as the problem diagrams
•
The signals of sequence diagrams at the external interfaces are the same as the signals in the interfaces of the application layer
•
The direction of all signals is consistent to each other and consistent to the input
•
The overall architecture contains all components of all subproblem architectures
•
The external interfaces of the components cover the interfaces of all problem diagrams
•
The signals in the sequence diagrams are the same as in the external interfaces
46
Chapter 4 Phase 2: Design
4.4 Step 8: Specify the behavior of all components of all software architectures using sequence diagrams In this step, the behavior of each component from the global software architecture is modeled using a sequence diagram.
A separate sequence diagram is drawn for each
sub-problem. The signals from global software architecture and the speci cations from Step 4 are re-used in this step. The sequence diagrams model the ow of data, actions and control between the sub-components of the global software architecture which is required in order to implement the corresponding sub-problem. The interface behavior of the components obtained from the sequence diagram forms the basis for the test speci cations.
Messages used in the sequence diagrams must be consistent with the
interface signals de ned in the previous steps.
4.4.1 Behavior of Software Components of ORCS Figure 4.6 shows the behavior of components with respect to the requirement
Req.3.1_2.1
Figure 4.6: Sequence diagram showing behavior of the components of the requirement
Req.3.1_2.1
Figure 4.7 shows the behavior of components with respect to the requirement
47
Req.3.1_2.2
Chapter 4 Phase 2: Design
Figure 4.7: Sequence diagram showing behavior of the components of the requirement
Req.3.1_2.2
Figures 4.6 and 4.7 show the sequence of interactions taking place between the components of the global architecture for satisfying the corresponding requirements. They show the sequence and the direction of messages from one component to the other. Also when we compare the messages in the sequence diagram with the interface signals de ned in previous section, they get mapped correctly. This mapping is shown in Table 6.1 in Section 6.3. These messages give an insight into the further implementation details. Likewise the sequence diagrams at the component level for all requirements are drawn and veri ed. The validation conditions of Step 8 are satis ed as follows:
•
All signals in the interfaces classes of Step 7 are captured in at least one sequence diagram
•
The direction of the signals are consistent with the required or provided interfaces of Step 7
•
The signals connect the same components as connected in the software architecture of Step 7
4.5 Step 9: Specify the software components of all software architectures as state machines In this step, the behavior of each component is described in detail using state machine diagrams. A state machine diagram describes the internal transitions within the compo-
48
Chapter 4 Phase 2: Design nents while execution. It includes preconditions which are needed in order to execute the transitions and postconditions that are the output of the transition. With an increasing level of detailed description, the better it is for the implementation.
The behavioral
characteristics of each component with respect to each sub-problem can be de ned using a state machine diagram. State machine diagrams drawn in this step enhance and re ne the behavior described in the previous steps using sequence diagrams.
4.5.1 ORCS State Machine Diagram As described in Step 9 of DePES, state machine diagrams are drawn for every component of ORCS. Each diagram depicts the sequence of execution, internal state transition, and pre/postconditions. From the architecture diagram in Step 7, we know that the component
Sequence Controller
is the decision making component of
ORCS
(for
Req.3.1_2.2).
The regime calculation which is the core logic of ORCS is based on the helicopter's control data received from the HAP HR. The behavior of the component
Sequence Controller
with respect to regime calculation is shown in Figure 4.8 with the help of a state machine diagram.
Figure 4.8: State machine diagram describing the behavior of the component
Controller
of
ORCS
Sequence
Figure 4.8 shows details of regime switching. Dierent regimes are represented using the states of state machine diagram. The regimes are de ned by coding control signal inputs of a helicopter for its 4 axes namely Roll, Pitch, Collective and Yaw. The control signals are named as follows:
49
Chapter 4 Phase 2: Design Pitch
Roll
Yaw
Collective
1
RC
RC
RC
RC
2
ACAH
ACAH
TC
RCHH
3
ACVH
TRC
RCDH
-
4
TRC
PH
-
-
5
PH
-
-
-
Table 4.1: Coding of Regimes based on the control signals and axes of a helicopter
ACAH: Attitude Command with Attitude Hold ACVH: Attitude Command with Velocity Hold PH: Position Hold RC: Rate Command RCDH: Rate Command with Heading (Direction) Hold RCHH: Vertical Rate Command with Altitude (Height) Hold TC: Turn Coordination TRC: Translational-Rate-Command For each axis, a number is given to its control signal and regime is formed by concatenating these 4 numbers. One number for each axis. The coding for regime is shown in Table 4.1. For example, Regime 2232 describes that control signal for the axis Pitch is ACAH, for the axis Roll is ACAH, for the axis YAW is RCDH and for the axis Collective is RCHH. Further details about the regimes could be found in [Abi09].
Regime 4332 is the default regime. Whenever ORCS start executing, the initial regime would be Regime 4332. Other than this initial regime, there are 6 more regime within which ORCS can switch depending on the input. The speci c input values from HR form the preconditions for the regime switching. The expected switched regime would be the postcondition. The transitions between the regimes are possible by the generation of an event. There are 4 possible events named as transitionCooliHatUp, transitionCooliHatDown, transitionVelocityUp and transitionVelocityDown which could be generated. The event transitionCooliHatUp and transitionCooliHatDown take place when the coolie hat on either side or center stick of a helicopter is pressed up or down respectively. From
Req.3.1_2.1, we know that the event Coolie Hat Up/Down in the real world is conveyed to ORCS by the HAP HR by sending the signals such as ActiveStickStatus, SidestickPosition and CenterstickPosition. So the values stored in HAP Data Container would be the preconditions for the event transitionCooliHatUp. It is speci ed as follows: Precondition:
(ActiveStickStatus == 5&&SidestickU p == 1)|| (ActiveStickStatus < 5&&CenterstickU p == 1) Postcondition: Event transitionCooliHatUp = true
Now when an event
transitionCooliHatUp
is generated, a regime switching would take
Regime 2232 and an event transitionCooliHatUp is generated then the regime would be switched to Regime 4332 as shown in Figure 4.8. The event transitionCooliHatDown could be explained similar to the event transitionCooliHatUp. The event transitionVelocityUp would be generated when the velocity of the helicopter exceeds the prede ned threshold value. From Req.3.1_2.1, ORCS stores the current velocity of the helicopter inside HAP Data Container which it receives from the HAP HR. The pre and postconditions for the event transitionVelocityUp
place as indicated in Figure 4.8. For example, the current regime is
50
Chapter 4 Phase 2: Design can be speci ed as follows:
Precondition:
CurrentHelicopterV elocity > 10
knots
1
Postcondition: Event transitionVelocityUp = true
transitionVelocityUp is generated, a regime switching would take place as indicated in Figure 4.8. For example, the current regime is Regime 1111 and an event transitionVelocityUp is generated then the regime would be switched to Regime 1121 as shown in Figure 4.8. The event transitionVelocityDown could be explained similar to the event transitionVelocityUp.
Now when an event
Similarly for every component and sub-problem of ORCS, a state machine diagram is drawn which demonstrates the executional behavior of each component with respect to a particular sub-problem. The pre and postconditions described in this step would be very helpful while implementing the behavior of the components. The validation conditions of Step 9 are satis ed as follows:
•
The state machines are consistent with the interface behavior from Step 8.
All
states are covered
•
Each architectural component is covered, and in all state machines each possible input signal (as speci ed in Step 7) is taken into account.
•
1
The interface classes are the same as in Step 7
The knot is a unit of speed used in the aviation industry which is equal to 1.852 km/h
51
Chapter 5 Phase 3: Implementation Controlling complexity is the essence of computer programming. Brian Kernighan
In this phase the actual implementation is carried out using an appropriate programming language and a development tool. In the current section we will take a look on how we can implement a software which is defect free and satis es the desired requirements based on the analysis and design models created in the previous phases.
5.1 Step 10: Implement software components and test environment The implementation (programming) is based on the global and component architecture and behavior of architectural components speci ed in Chapter 4. The architecture diagrams are drawn with the help of internal block diagrams in Section 4.3 while the behavior of the components of the architecture diagrams is described using sequence and
state machine diagrams of SysML in Section 4.4 and Section 4.5. Since we are using an object oriented software development approach in DePES, the basic unit of implementation is a Class and its Object.
For the implementation of software
components, classes are created corresponding to the components created in architecture diagrams. In DePES, the classes and the relationships between them is modeled using a UML class diagram. In our approach, we propose to use a block de nition diagram of SysML for representing the class structure of a software. A block is created for each component in a software component architecture diagram.
The relationships between the components of archi-
tectural diagram can be modeled using the elements such as aggregation, composition,
dependency, association and inheritance of the block de nition digram. Each block could be populated with attributes and operations. The implementation of the components is performed by adding the required attributes and operations to the blocks. The attributes and operations are derived from the behavioral speci cation of the components obtained in Steps 8 and 9.
The visibility of the attributes and the operations could be de ned
as public or private or protected.
The detailed implementation can be added to each
operation depending on its role. The provided and required interfaces describe the functional distribution.
The operations of the provided interface of a component becomes
the operations of the class representing that component. For the required interfaces of a component, the corresponding class needs to establish an appropriate relation with the class which represents a component providing that particular operation. So likewise architecture diagrams can be transformed into class diagrams with the implementation
52
Chapter 5 Phase 3: Implementation details.
R
,
There are many model-based software development tools like IBM Rational Rhapsody
Eclipse plugins etc. which provide the facility of automatic code generation. Using such tools, we can add attributes, operations and detailed logic implementation within the classes (blocks) of the class diagram and a program would be generated automatically. Such an automatic code generation would be in synchronized with the design. If the tool does not provide an automatic code generation then based on the class diagram, manual coding has to be done. In such cases, extra care has to be taken in order to keep the code and the design synchronized.
5.1.1 ORCS Implementation R
Designer for Systems Engineers edition is used for ORCS deR
velopment. IBM Rational Rhapsody facilitates an automated code generation. The R
model-code associativity feature of the IBM Rational Rhapsody ensures the synchroIBM Rational Rhapsody
nization between the developed design model and the generated code. IBM Rational R
Rhapsody can generate the code in many programming languages e.g., C, C++, JAVA etc. We decided to use C++ for the implementation of ORCS. The class diagram of ORCS is drawn using block de nition diagram as shown in Figure 5.1.
Figure 5.1: Class Structure of
ORCS
using a Block de nition diagram of SysML
As shown in Figure 5.1, 6 classes are created corresponding to the 6 components described in the software component diagram of ORCS shown in Figure 4.5. The correspondence between the classes and the components can be easily mapped using their names. ORCS is implemented using the classes namely MainORCSBlock, UDPCommunicationBlock, DataParserBlock, DataLoggerBlock, SequenceControllerBlock and HAPDataContainerBlock. The functionalities that each class carries out are based on the responsibilities of components which were decided while designing the architecture of ORCS in Chapter 4. The attributes and the operations are added to each component based on the messages described in the sequence and state machine diagrams. Also the relationships between these components and the corresponding requirements is visually represented
53
Chapter 5 Phase 3: Implementation MainORCSBlock is related to the other classes UDPCommunicationBlock, DataParserBlock and DataLoggerBlock via a composite relation while it is related to the classes SequenceControllerBlock, and HAPDataContainerBlock via a usage relation. As the name suggests MainORCSBlock is the top level class of ORCS. It de nes the main() function of ORCS
in Figure 3.3 using satisfy relation provided in requirements diagram. The class
which initializes all objects according to the architecture from Step 7. It initiates and controls the data and the control ow between the other classes. This is illustrated in Listing 5.1 with respect to data processing of HR. The purpose and the characteristics of the attributes and the operations are described in the description eld of the class (block).
The consistency between the mapping of
messages and operations must be maintained in order to synchronize the modeling and R
implementation artifacts. Since we are using IBM Rational Rhapsody for ORCS development, its model execution and back animation feature takes care of any formal consistency. The interfaces in the architecture diagram are implemented using directly called methods. The provided interfaces become the functions of the classes which represents components providing them. In order to use these services,
MainORCSBlock establishes relations with
these provider components by having objects of these classes as its private data mem-
UDPCommunicationBlock provides functions such initUDPcommunication, initWinsock, createSocket, ndInitFileValue, send, receive and shutdownWinsock required for the UDP communication between ORCS and other HAPs. Since, the class UDPCommunicationBlock which is related to the class MainORCSBlock through a composite relation, the class MainORCSBlock can use these functions using its private data member udpComm which is an instance of the class UDPCommunicationBlock. Figure 5.2 shows the structure of classes MainORCSBlock and UDPCommunicationBlock ber. For example, in Figure 5.2, class as
in detail. We know that the component
ControllerBlock
Sequence Controller
and then in turn the class
Sequence-
provides decision making functionality of ORCS. The decision making
system of ORCS is event-based. Therefore, the
SequenceControllerBlock
is implemented
as an event-based class using an Object Execution Framework (OXF) element called
OMEvent. An OXF is a framework for an object oriented programming [IBM08b]. It consists of a collection of classes that provide services for dierent tasks which can be R
customized through inheritance. IBM Rational Rhapsody uses the OXF for generating the source code for real-time or embedded software systems. The behavior of the decision making system is de ned using a state machine diagram in Step 9. This state chart is directly linked with the class
SequenceControllerBlock.
As of now
SequenceControllerBlock
class consists of just one state chart implementing Regime Recognition. In future, within the proposed state charts features like calculating mission states and trajectory tracking states would be added and linked. The trajectory tracking de nes three dierent ight phases: start, Enroute and Landing. Depending on the way points,
ORCS would calculate
the state which would be further used for the route planing of a helicopter. In total 6 mission states are de ned namely None, On ground, Start, Enroute, Approach, Landing and Hover for HAP AS. In future,
ORCS
would identify the correct mission state based
on the sensor and trajectory tracking information and convey it to AS. The Listing 5.2 illustrates the process of detection of an event based on the HR input data while the Listing 5.3 shows how event is generated using OMEvent class. Similarly all other classes can be implemented which satis es the functionalities expected from their corresponding component in the architecture diagram.
54
Chapter 5 Phase 3: Implementation
Listing 5.1: Source Code of the function
startECUDPCommunication
showing control and
data ow 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
bool senderflag = true ; int checkCosMode =0; int frame = 0;
// received packet processing hrInput = new HAPDataContainerBlock :: HRInputData_C () ; hrInput = parser - > parseHRInputData ( inputData ); indataLogger -> writeHRInLogFile ( hrInput ); indataLogger -> writeWarningLogFile ( hrInput );
i f ( senderflag )
{ }
checkCosMode = hrInput - > cos_mode ; seqControl - > resetRegimeRecognition () ;
e l s e i f ( checkCosMode != hrInput -> cos_mode )
{ }
seqControl - > resetRegimeRecognition () ; checkCosMode = hrInput - > cos_mode ;
i f (( int ) hrInput - > cos_mode > 5 && ( int ) hrInput -> cos_mode < 11)
{
std :: cout writeHROutLogFile ( hrOutput ); outputData = parser - > parseHROutputData (id , frame , hrOutput );
i f ( senderflag )
{ }
}
udpComm -> createSocket ( " senderEC ") ; senderflag = f a l s e ;
int ret = udpComm -> send ( id , outputData ); std :: cout fss_vtas ) > 10) { enVelocityUp = true ; velocityUpIsSwitchable = f a l s e ; velocityDownIsSwitchable = true ; std :: cout
