Modeling in Modelica and SysML of System Engineering at Scania Applied to Fuel Level Display

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Modeling in Modelica and SysML

of System Engineering at Scania

Applied to Fuel Level Display

by

Feng Liang

LIU-IDA/LITH-EX-A--12/045—SE

2012-08-30

(2)

(3)

Final Thesis

Modeling in Modelica and SysML

of Engineering of Systems at Scania

Applied to Fuel Level Display

by

Feng Liang

LIU-IDA/LITH-EX-A--12/045—SE

2012-08-30

Supervisor: Olena Rogovchenko, IDA, LiTH

Mattias Nyberg, Scania CV AB

Examiner: Peter Fritzson, IDA, LiTH

(4)

(5)

Abstract

The main objective of this thesis is to introduce a four perspectives struc-ture in order to provide one solution for traceability and dependability in the system design phase. The traceability between different perspectives help engineers have a clear picture of the whole system before goes to the real implementation.

Fuel Level Display system from Scania Truck is used to undertake as a case study to offer insights of the approach. A four perspectives structure is made in the first place in order to analysis traceability between different viewpoints. After implementing the Fuel Level Display system in Modelica, a verification scenario is specified to perform a complete requirement verifi-cation process for system design against requirements.

Keyword: Model Based System Engineering, Modelica, SysML, Require-ment Verification

(6)

(7)

Acknowledgements

Foremost, I would like to express my sincere gratitude to my supervisor Mattias Nyberg from Scania CV AB for his valuable suggestions and en-courage on my thesis. I gratefully acknowledge my partner Sarah Sadeghi from KTH Royal Institute of Technology for all the discussions. It would not have been possible to finish this project without her support.

I am greatly indebted to my examiner Professor Peter Fritzson and super-visor Olena Rogovchenko at The Department of Computer and Information

Science(IDA), Link¨oping University for their help and guidance throughout

the thesis.

My sincere thanks also go to Jonas Westman, Magnus Selld`en, Thomas

Näreskog, Ola Ramström, Jonas Edèn, Gunnar Berg from Scania CV AB

for all the discussions about Scania Technical and Functional Architectures. Last, but not least, I would like to thank my fiancee Ruinan, her support and encouragement was in the end what made this thesis possible.

Feng Liang,

(8)

(9)

List of Figures

1.1 Scania’s Truck R730 with V8 Engine. . . 6

1.2 Scania’s modular System. . . 6

1.3 Complex E/E system in Vehicles . . . 7

1.4 SysML Diagram Taxonomy . . . 8

2.1 The Model Based System Design Process. . . 11

2.2 Requirement Classification. . . 12

2.3 The Relation of Test Scenario and Requirement . . . 14

2.4 Verification Library . . . 15

2.5 Verification block for Functional Requirement of Real Type . 15 2.6 Verification block for Performance of Real Type . . . 16

3.1 ECU Map of SESAMM. . . 18

3.2 Allocation Elements Map in SESAMM. Allocation Elements are connected to each other, which constitute a complete SESAMM system. . . 19

3.3 User Function and Allocation Element. From the figure we can see that different User Functions are connected with each other by common Allocation Element, which means that one user function is connected to all Allocation Elements. . . 20

3.4 Relation between functions to physical components . . . 21

4.1 Dash Board in Scania Truck . . . 22

4.2 In the Technical Architecture of Fuel Level Display, three ECUs are involved,Coordinator ECU(COO), Engine Manage-ment System(EMS), InstruManage-ment Cluster System(ICL). . . 23

4.3 Fuel Level Display Process . . . 24

4.4 User and Logical Perspectives . . . 27

4.5 Technical Perspective . . . 28

4.6 Requirement Perspective . . . 29

4.7 Relations Between Different Perspectives . . . 30

4.8 Modelica Structure . . . 32

4.9 Level 1 Structure of Modelica Model . . . 33

(12)

LIST OF FIGURES LIST OF FIGURES

4.13 Simulink Model with Dymola Interface . . . 37

4.14 Test Scenario . . . 38

4.15 Simulation Result of Test Scenario . . . 38

4.16 Simulink Model Verification Against User Function Require-ment 18: Displayed Fuel Level . . . 39

4.17 Simulink Model Verification Against User Function Require-ment 18: Low Fuel Level Warning . . . 40

5.1 Requirement Document Deficiency . . . 42

(13)

Glossary

System Architecture The composite of the design architectures for prod-ucts and their life cycle processes.[1]

Electronic Control Unit (ECU) ECU is a generic term for any embed-ded system that controls one or more of the electrical systems or subsystems.[26]

Electronic Control Unit System (ECU-System) ECU-System is a set of components such as sensors,actuators,cabling etc. and an ECU con-nected to one of the CAN-buses.[14]

Discrete Electric Circuit System (DEC-System) ECU-System is a set of components such as sensors,actuators,cabling etc. with no ECU at all or an ECU not connected to any of the CAN-buses.[14]

Acausa Connection Acausa Connection is the connector that the data flow in the connection is not explicitly specified.[12]

Causa Connection Causa Connection, also called signal connections, where the direction of data flow is specified using prefixes input or output in the declaration of at least one of the connectors in the connection.[12] Coordinator ECU (COO ECU) The COO ECU works as a gateway for communicate with other ECUs in Scania electrical system SESAMM. Allocation Element (AE) Allocation element is a logical module used in Scania functional architecture. It consist of several functions that can achieve one or more User Function but not owned by any specific User Function. An allocation elements is not depend on any hardware and able to allocate to any Scania ECU.

Allocation Element Requirement (AER) Allocation element require-ment is the requirerequire-ment for allocation elerequire-ment. In Scania, it realized by allocation element requirement documents.

User Function (UF) Allocation element requirement is the requirement for allocation element. In Scania, it realized by allocation element requirement documents.

(14)

LIST OF FIGURES LIST OF FIGURES

Allocation Element Requirement (AER) A user function creates a clear advantage for the user, i.e., the user has a distinct motive for why he uses the system. This feature is implementation independent, where we see the entire electronics system(SESAMM) as the provider of the function, not the individual ECU systems.[8]

Allocation Element Requirement 201(AER201) Allocation Element Requirement for Fuel Level Estimation.

Allocation Element Requirement 202(AER202) Allocation Element Requirement for Low Fuel Level Warning.

Function Safety Functional safety absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.[3] Hazard Potential source of harm caused by malfunctioning behavior of the

item.[3]

Electrical and/or Electronic system (E/E system) System that con-sists of electrical and/or electronic elements, including programmable electronic elements. e.g Power supply, sensor or other input device; communication path; actuator or other output device.

System Life Cycles A life-cycle addresses all phases to include system de-sign and development, production and construction, distribution, op-eration, maintenance and support, retirement, phase-out, and disposal.[5] Model-based System Engineering (MBSE) The formalized application

of modeling to support system requirements, design, analysis, verifica-tion and validaverifica-tion activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.[11] Test Case A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.[1]

(15)

Chapter 1 Introduction

This thesis work is carried out with my partner Sarah Sadeghi from School of Information and Communication Technology, KTH Royal Institute of Tech-nology. Sara and me work together for understanding the Technical and Functional Architecture in Scania, the Four Perspectives Structure model and implement the case study in Modelica. After creating models in Model-ica, I am focusing on simulating the structure with Simulink and requirement verification and Sara absorbed in making general Meta model which includes all the required documents, technical and functional architectures in Scania. Two separate thesis reports were written for KTH Royal Institute of

Technology and Link¨oping University respectively.

1.1 About Scania

This master thesis project is carried out in Scania CV AB S¨odert¨alje. Scania

is one of the world leading manufacturers of heavy trucks and buses with

more than 110 year history. In 1900, Scania was founded in Malm¨o, a city

located in south of Sweden, for producing bicycles. In 1911, Scania and another Swedish company Vabis are combined and start to manufacture buses and trucks. Currently, Scania operates in about 100 countries and has become one of the biggest trucks and bus manufacturers in the world.

(16)

1.1. ABOUT SCANIA CHAPTER 1. INTRODUCTION

Figure 1.1: Scania’s Truck R730 with V8 Engine.

Scania’s unique modular product range is one of its most important suc-cess factors. The modular concept was first invented in 1930s and developed for more than 80 years. This new modular product system limits the num-ber of components, which is cost-effective and halved development costs [17] The modular concept not only means that vehicles can be satisfy the needs of individual customers. It also provides the opportunity to increase or maintain the individual component.

(17)

CHAPTER 1. INTRODUCTION 1.2. BACKGROUND

1.2 Background

Electrical and Electronic (E/E) System in vehicles has increased rapidly since early 1970s starting with electronic ignition and electronic voltage regulator. With 40 years development, the Electrical and Electronic (E/E) System has covered a wide range of applications to improve the performance of vehicles. Today’s vehicles use around 30 ECUs for small cars and 80 ECUs for high-end luxury cars[15]. And the number of ECUs is still expanding based on the huge demands from the market. Complex E/E systems brings more functions to vehicles but it also enhances the difficulty of analysis a particular function.

Figure 1.3: Complex E/E system in Vehicles

In order to design a complex system that satisfy the customers’ needs, enhance the safety and reduce the total cost, System Engineering is intro-duced to meet all these requirements. Following is a definition of System Engineering introduced by NASA,

”Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system[2].”

The traditional document-based approach indicates that all the require-ments or system artifacts are written in the document files. These docu-ments are transfer information among stakeholder, designers and testers by natural language or graphical figures. The document-based approach could provide rigorous requirements, however, it also has fundamental limitations. Document-based approach is hard to analysis the traceability and consis-tency between requirements and system design because they are recorded in different documents. For the traditional document-based approach, the re-quirements and system artifacts is written in natural language. The natural

(18)

1.3. SYSML CHAPTER 1. INTRODUCTION

language could rise additional discussions. In 1993, Wymore first introduced a new Model-based System Engineering (MBSE) approach[7]. Compared with traditional document-based approach, the Model-based System Engi-neering (MBSE) significantly improve the efficiency of developing a com-plex system. Friedenthal (2008) proposed the potential benefits of MBSE: Enhanced communications, Reduced development risk, Improved quality, Increased productivity and Enhanced knowledge transfer[11].

1.3 SysML

The Systems Modeling Language(SysML) is first introduced in January 2001 by the International Council on Systems Engineering (INCOSE)[18]. SysML has a strong capacity to capture the textual requirement, provide traceability model and allocate the requirement to designed System. SysML is defined as an extension of the Unified Modeling Language (UML). Compared to the traditional UML, two new diagrams,requirement and parametric diagram, are added in SysML. These two diagrams can be used for Requirement En-gineering and verification which are important parts of System EnEn-gineering.

Figure 1.4: SysML Diagram Taxonomy

However, SysML also has its limitations. SysML is semantic fully defined but it does not have a capability to model an excusable physical system. In order to verify whether the requirements are being violated or not. An excusable model which integrates the requirements and physical components will be modelled in the equation-based language Modelica.

(19)

CHAPTER 1. INTRODUCTION 1.4. MODELICA

1.4 Modelica

Modelica is an object-oriented equation-based language with a class concept

for modeling complex physical or Cyber-Physical System(CPS)1_{. It can be}

used in multi-domain modeling, for instance, mechanical system with control signal, robotic system with electronic circle.

The Modelica Association is a non-profit organization with members from Europe, the U.S. and Canada. Since 1996, it focuses on developing the open source standard Modelica Library. Modelica Simulation Environments are available both commercially and free of charge, commercial environment such as CATIA Systems, Dymola, LMS AMESim, MathModelica, Sim-ulationX and free environment likes OpenModelica and JModelica.org.[4] The Modelica Language is warmly received in different area of automotive, robotics, aerospace.

Acausal modeling is one of the most important features of Modelica. Causal connections also called signal connections, where the direction of data flow is specified using the prefixes input or output. Acausal port means that the data flow in the port is not specified.

1.5 Virtual Verification of Designs against

Re-quirements(vVDR)

The methodology used in this thesis is based on vVDR approach. vVDR (Virtual Verification of Designs against Requirements) is a methodology that enables automatically requirement verification against system design.[21] The whole verification process is describes in paper.[20] In vVDR, Modeli-caML is used as the main Modelica modeling environment which enables user to binding requirement model and verification model automatically. And also ModelicaML enables different design alternatives.[20]In this thesis work, the Modelica environment Dymola is used instead of ModelicaML in vVDR approach.

ModelicaML supports all Modelica constructs and, in addition, supports an adapted version of the UML state machine and activity diagrams for behavior modeling as well as UML class composition diagrams for structure modeling. This enables engineers to use the simulation power of Modelica combined with a standardized graphical notation for the creation of system models[16].

1.6 Goal and Scope

In this thesis work, a new methodology of requirement verification is intro-duced to meet all the requirements.

1_{Cyber-Physical Systems (CPS) is a system that integrates both physical and}

(20)

1.6. GOAL AND SCOPE CHAPTER 1. INTRODUCTION

The purpose of this thesis work is trying to develop a structure that pro-vides traceability between integrates two different architectures, functional and technical, inside one Modelica model. The Modelica model can provide the traceability of requirement and requirement verification. So this thesis project is trying to answer two questions:

• Find out structure for development of artifacts like Requirement, Spec-ification, Architecture, Functions, and Simulink-Models, etc.

• Investigate Modelica/Dymola as a common language/tool for the de-velopment of artifacts in the industrial context

• Develop a methodology for model based system design against require-ment verification.

(21)

Chapter 2 Methodology of

Requirement Verification

Figure 2.1: The Model Based System Design Process.

Figure 2.1 shows the methodology of System Design and Requirement Verification used in this thesis work. First of all, all the requirements need to be classified. After classification, select requirements that are able to be verified by the simulation model. Then model the technical system based on the Scania technical architecture in Modelica Modeling environment. In the end, based on the classification of requirement, perform corresponding method to verify the design against requirements.

2.1 Requirement Selection

2.1.1 Requirement Classification

The classification of requirement is important since it affects the requiment verification process. However, the is no consensus in the field of re-quirement classification. The common sense divided the rere-quirement into functional requirement and non-functional requirement which answers the questions ”what the system does” and ”how the system behaves with re-spect to some observable attributes like performance, re-usability, reliability,

(22)

2.1. REQUIREMENT SELECTION

CHAPTER 2. METHODOLOGY OF REQUIREMENT VERIFICATION etc”[10], respectively. However, in the practice of requirement engineering, it turns out that a more detail of non-functional requirement classification is needed. Martin Glinz[13] proposed a taxonomy for both functional and non-functional requirements.

Figure 2.2: Requirement Classification.

Figure 2.2 illustrate taxonomy proposed by Martin Glinz. The system re-quirement can be partitioned into functional rere-quirement and non-functional requirement. Since the need of sub-classification of non-functional requiment, the non-functional requirement can be classified as performance re-quirement, specific quality requirement and constraints. Following is a def-inition for each taxonomy[13],

Function Requirement Function Requirement is a requirement that spec-ify the system’s behavior, data input or reaction to input stimuli. Performance Performance is a requirement to specify the timing, space,

speed etc inside a desired range.

Specific Quality Requirement Specific Quality Requirement is a require-ment that specify the quality the system should have like reliabil-ity,usability, maintainability etc.

Constraint Constraint is a requirement that constrains the solution space beyond what is necessary for meeting the given function, performance and specific quality requirements.

(23)

CHAPTER 2. METHODOLOGY OF REQUIREMENT

VERIFICATION 2.2. FORMALIZING DERIVED REQUIREMENTS

ditional judgment from the stakeholder. For instance, the Specific Quality Requirement which specifies the quality of the system need to be verified from the experience of stakeholder. In addition, some requirements are im-possible to be verified by simulation model. For instance,

AER 201 6 The fuel level shall be able to reach all values from

0% to 100%.

AER 201 7 If the truck has one fuel level sensor it should be

connected to pin A12 on COO and ground to Pin A3.

Requirement AER 201 7 will not be selected since it is not sufficient to be verified by simulation model. In contrast to that, requirements consist of mathematical expressions or boundaries are more suitable for the verifi-cation process. Requirement AER 201 6 is more suitable to be verified by simulation model compared to AER 201 7.

2.2 Formalizing Derived Requirements

After selecting requirements, the next step is to formalizing selected require-ments. All the requirements are written in natural language. Nevertheless, all the textual requirements need to be translated into Modelica expressions, following is an example,

AER 202 2 The lowFuelLevelWarning should be set to 1 (true)

when input totalFuelLevel is below a pre-defined level. The level should be 10% for tank sizes equal or below 900 liters and 7% for tanks sizes larger than 900 liters.

Here is a textual requirement AER 202 2 which sets requirement for low fuel level warning. If the fuel level in the tank is lower than a predefined value, the warning lamp should be enabled. The textual requirement is not able to be implemented in Modelica model, thus it needs to be translated to Modelica expression. The requirement AER 202 2 is translated into fol-lowing Modelica expression,

if t a n k S i z e <=900 t h e n if t o t a l F u e l L e v e l < (t a n k S i z e*0 .1) t h e n l o w F u e l L e v e l W a r n i n g = t r u e; e l s e l o w F u e l L e v e l W a r n i n g = f a l s e; end if; e l s e i f t a n k S i z e > 9 0 0 t h e n if t o t a l F u e l L e v e l < (t a n k S i z e*0 .07) t h e n l o w F u e l L e v e l W a r n i n g = t r u e;

(24)

2.3. SYSTEM DESIGN

CHAPTER 2. METHODOLOGY OF REQUIREMENT VERIFICATION e l s e l o w F u e l L e v e l W a r n i n g = f a l s e; end if; e l s e l o w F u e l L e v e l W a r n i n g = f a l s e; end if;

2.3 System Design

After formalizing all the selected requirement, following is the actual system design. In this thesis work, the traceable structure is first made in SysML and then implement the structure into Modelica. The Modelica model will be built in Modelica modeling environment Dymola (Dynamic Modeling

Laboratory) from Dassault Syst´emes1_.

2.4 Requirement Verification

After having designed the whole system, the next step is to verify whether the designed system fulfills the requirements. The verification process is performed by executing pre-defined test scenario. Figure 2.3 illustrate the relation between test scenario and requirement. As can be seen from the figure, a test scenario can be used to verify several requirements. And also, several test scenario can be used to test one requirement.

Figure 2.3: The Relation of Test Scenario and Requirement

After defining the test scenario, the verification method should be done .As it mentioned in Section 2.1, the verification process is affected by the classification of requirement. Figure 2.2 shows a classification of ments both functional and non-functional. However, some of the require-ments are not suitable to be verified by simulation model, the verification process will only focus on two types of requirement, Functional

(25)

Require-CHAPTER 2. METHODOLOGY OF REQUIREMENT

VERIFICATION 2.4. REQUIREMENT VERIFICATION

Real, Integer, Boolean, String and Enumeration. Among them, Real, In-teger and Boolean are considered in the verification process since they are most commonly used in mathematical models.

Figure 2.4: Verification Library

Functional Requirement

Functional requirement is a requirement that describes system reaction against input stimuli. It may consist of a mathematical model or other expressions. The verification block for Functional Requirement is checking whether the input signal align with the requirement.

Figure 2.5: Verification block for Functional Requirement of Real Type

Performance

Performance is a requirement to specify an acceptable range of particular behavior of the system. So the verification block in Modelica consists of three inputs, lower bound, upper bound and signal to be verified. If the

(26)

2.4. REQUIREMENT VERIFICATION

CHAPTER 2. METHODOLOGY OF REQUIREMENT VERIFICATION input signal varies in defined boundary, the verification result returns true, otherwise false.

(27)

Chapter 3 Technical and Functional

Architecture in Scania

3.1 Technical architectures in Scania:SESAMM

With the increasing functional demands of the market, electronic system of vehicles is becoming more and more complex. In order to simplify the

sys-tem, a new concept called SESAMM1_{for Scania Trucks and Buses electrical}

systems come out[14]. SESAMM was initially started in 1994 with the aim of modernizing elplattformen to SCANIA’s truck and bus applications. The project was initiated by Lars Gardell with the working title Scania Electrical Anno 2000 (MM)[23]. The overall aim for the SESAMM model concept is to make it possible to analyze dependencies and to allow functional changes and functional growth in Scania electrical system[19].

3.1.1 ECU System

Electronic Control Unite System(ECU System) is the basically element of SESAMM, an ECU System is defined as,

”ECU-System is a set of components such as sensors,actuators,cabling etc. and an ECU connected to one of the CAN-buses.[14]”

The Figure 3.1 illustrate the ECU configuration of SESAMM, all the ECUs are divided into three different groups in order to keep safety-critical ECUs apart from less safety-critical ECUs. The Red bus connects all the ECUs which are most important for the safety of the vehicle. In contrast to that, the green bus connects all the ECUs that are not safety critical compared with red and yellow buses.

1_{SESAMM is short for Scania Electrical System Architecture Made for Modularization}

(28)

3.2. FUNCTIONAL ARCHITECTURE

CHAPTER 3. TECHNICAL AND FUNCTIONAL ARCHITECTURE IN SCANIA

Figure 3.1: ECU Map of SESAMM.

3.1.2 DEC System

Discrete Electric Circuit System(DEC System) is defined as,

”DEC-System is a set of components such as sensors,actuators,cabling etc. with no ECU at all or an ECU not connected to any of CAN-buses. [14]”

The most common DEC system is the Power Supply System which feeds all ECUs with direct wire without any ECU inside.

3.2 Functional Architecture

In Scania Functional Architecture, there exist three important terms in func-tion architectures, Allocafunc-tion Element(AE), Funcfunc-tional Variable(FV) and

(29)

CHAPTER 3. TECHNICAL AND FUNCTIONAL ARCHITECTURE IN

SCANIA 3.2. FUNCTIONAL ARCHITECTURE

3.2.1 Allocation Elements AEs

”An allocation element (AE) is an allocation of independent el-ements that indirectly or directly implel-ements one or more user functions. It can not be divided among multiple ECUs but can be in several. The Allocation Elements are named after the element performing the task, not part of a work flow or task.[8]”

Allocation Element (AE) is a reusable logic module which has predefined task and contributes to achieve one or more User Functions. It is not owed by any specific UF or any specific hardware component. Before Allocation Element (AE) introduced, it is almost impossible to understand how the User Functions are realized in ECUs. With Allocation Element (AE), the dependencies of User Functions are possible to be analyzed and allow the maintain or functional growth in the future. The Allocation Element mainly allocates to the application software components of ECUs. It represents the relationship between different Function Variables in SESAMM.

Figure 3.2: Allocation Elements Map in SESAMM. Allocation Elements are connected to each other, which constitute a complete SESAMM system.

3.2.2 Function Variables FVs

Function Variable (FV) is an abstraction of the information which communi-cate between different Allocation Elements. The relation between FVs and AEs is illustrated in Figure 3.3. In practice, Function Variable corresponds to one or more signal including CAN-signals, LIN-signals and direct wire. However, since Allocation element is not allocated to particular ECU, Func-tion Variable may corresponds to internal informaFunc-tion about ECU as well. For instance, two Allocation Elements are allocating to same ECU, so

(30)

Func-3.2. FUNCTIONAL ARCHITECTURE

CHAPTER 3. TECHNICAL AND FUNCTIONAL ARCHITECTURE IN SCANIA tion Variables between these two Allocation Elements are corresponding to internal information inside one ECU.

Figure 3.3: User Function and Allocation Element. From the figure we can see that different User Functions are connected with each other by common Allocation Element, which means that one user function is connected to all Allocation Elements.

3.2.3 User Functions UFs

The User function is defined as,

”A user function creates a clear advantage for the user, i.e., the user has a distinct motive for why he uses the system. This feature is implementation independent, where we see the entire electronics system(SESAMM) as the provider of the function, not the individual ECU systems.[8]”

A user function consist of one or more customer demands and independent from other user functions. However, different user functions can share same Allocation Element. In other words, all the user functions are connected with each other by common Allocation Elements. The implementation of a User Function can be involved zero(DEC System only), one or several ECUs.

(31)

CHAPTER 3. TECHNICAL AND FUNCTIONAL ARCHITECTURE IN

SCANIA 3.2. FUNCTIONAL ARCHITECTURE

Figure 3.4: Relation between functions to physical components In practice, two different User Functions can share one common Alloca-tion Element. AllocaAlloca-tion Element is a logical module, it is able to allocate to several different ECU software like Allocate Element in Figure 3.4. Mean-while, one ECU can be allocated by several Allocation Elements. The FVs between those AEs which allocate to different ECUs are corresponding to CAN buses signals between ECUs. The allocation implementation is de-scribed in the technical document Function Allocation Description (FAD).

(32)

Chapter 4 Case Study: Fuel Level

Display of Scania Truck

4.1 Introduction of Fuel level Display System

Fuel Level Display in vehicle is used for preventing driver run out of fuel. The fuel level display consists of two different functionalities, fuel level estimate and low fuel level warning. The fuel level estimate is used for calculating and display the current percentage level in the fuel tank. It should be able to display the fuel level continuously and detect the refill of tank and works for all variants of vehicles like Truck, Bus, Bus with gas engine and Truck with gas engine. The other function low fuel level warning should warn the driver by some visible symbol when the fuel level below a predefined value.

(33)

CHAPTER 4. CASE STUDY: FUEL LEVEL DISPLAY OF SCANIA

TRUCK 4.1. INTRODUCTION OF FUEL LEVEL DISPLAY SYSTEM

4.1.1 Technical Architecture of Fuel Level System

Figure 4.2: In the Technical Architecture of Fuel Level Display, three ECUs are involved,Coordinator ECU(COO), Engine Management System(EMS), Instrument Cluster System(ICL).

As can be seen from Figure 4.2, three ECU systems are involved in this Fuel Level Display function. The Engine Management System EMS calcu-late the fuel consumption in Engine and send to Coordinator System COO through Red CAN bus. The Coordinator System COO is use to gateway CAN-messages between different CAN-buses. In this case, the Coordinator System COO estimate the fuel level in tank and calculate whether the fuel level is lower than the predefined value. The Instrument Cluster System consist of dash board shows the driver current percentage of fuel level in tank and indicate driver when fuel level is low.

4.1.2 Functional Architecture of Fuel Level System

In Scania, the requirements for UF18, AE201 and AE202 are described in three technical documents respectively, UFR18, AER201 and AER202. However, only part of the requirements will be implement in Modelica. The requirements which selected for verification is showed in the Appendix B.

The User Function 18: Fuel Level Display is realized by two different Allocation Elements AE201 and AE202. These AEs should calculate and display the current percentage level in the fuel tank. The driver needs to be able to monitor the fuel level and AE202 needs the fuel level to calculate if the driver should be warned that the fuel level is low. These two Allocation Elements are allocate to application software domain of Coordinator ECU.

4.1.3 Fuel Level Display Process

One of the variant,truck,is considered in this case study. The following

(34)

4.2. REQUIREMENT CLASSIFICATION AND SELECTION

CHAPTER 4. CASE STUDY: FUEL LEVEL DISPLAY OF SCANIA TRUCK sensor measures the fuel level in tank and sends to coordinator ECU with Fuel Rate from Engine Management System EMS. The Coordinator COO consist two functionalities in this case, estimate the fuel level in tank and indicate the low fuel level in tank. All the signals are send to Instrument Cluster system ICL to indicate driver fuel level in tank and low fuel level warning.

Figure 4.3: Fuel Level Display Process

4.2 Requirement Classification and Selection

4.2.1 Requirement Classification

(35)

TRUCK 4.3. FOUR PERSPECTIVES OF FUEL LEVEL DISPLAY

mathematical expressions or boundaries are more suitable to be selected for the dynamic requirement verification process.

4.2.2 Requirement Selection

User Function 18 set requirements for the User Function of Fuel Level Dis-play, Allocation Element 201 and Allocation Element 202 set requirements for Fuel Estimation and Low Fuel Level Warning respectively. Following the principle mentioned in Chapter 2, all the requirement which suitable to be verify by dynamic simulation is listed in Appendix B.

4.3 Four Perspectives of Fuel Level Display

Since the system is becoming more and more complex, it becomes difficult to analysis the requirement, logical components and the relations between dif-ferent perspectives. In this section, we suggest a four perspectives structure in order to show different perspectives and its relationship of the system. The taxonomy is based on Contract-based Component System Design and the notation is reference to SysML notation. Following is a definition for each taxonomy,

Perspectives are viewpoints relevant to architecture modeling, as carried out by different stake-holders during the development process[6].

In this thesis work, we propose four different perspectives,

User Perspective is the functionalities which represents users or customers demand such as User Function 18(fuel level display)

Logical Perspective which describes the logical structure of the system, with their connections and relationships.

Technical Perspective Focuses on physical technical systems including communication buses, ECUs and power supplies.

Requirement Perspective Requirement for the logical perspective ele-ments of the system such as User Function and Allocation Element

4.3.1 User and Logical Perspectives

User and logical perspectives shows a decomposition of the functional archi-tecture of Fuel Level Display System. User perspective shows the user or customer demand or requirement of the system. In Scania, these require-ments are recorded by technical recorded User Function Requirement. In this case study, User Function 18(UFR18) embraces all the customer re-quirements for Fuel Level Display System. The other logical perspective

(36)

4.3. FOUR PERSPECTIVES OF FUEL LEVEL DISPLAY

CHAPTER 4. CASE STUDY: FUEL LEVEL DISPLAY OF SCANIA TRUCK describes the logical structure of system. These requirements are recorded in the technical report Allocation Element 201 and 202.

In Figure 4.4, there is a relation called realization illustrate the relation-ship between different terms. Following is the definition of realization

”Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the sup-plier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refine-ment, optimizations, transformations, templates, model synthe-sis, framework, composition, etc.”[22]

Figure 4.4 indicates the relationship between user and logical perspec-tive. In the logical perspective, there are five independent function units, Allocation Element 201 and 202 is realized by the excusable simulink model which consist of all the algorithms. The simulink model is able to generate the C code by Real-Time Workshop and implement in the ECU hardware after compiler. So the C code is a realization of simulink model and simulink model is a realization of function units Allocation Element 201 and 202.

(37)

Figure 4.4: User and Logical Perspectives

4.3.2 Technical Perspective

Technical perspective illustrate the technical breakdown of system, in this case study, only the main part of technical system is considered. So this thesis only focus on the breakdown of the Coordinator ECU(COO) which carry out the main calculation. As can be seen from Figure 4.5, SESAMM consists of different ECU systems, DEC system Power Supply and Cables.

(38)

CHAPTER 4. CASE STUDY: FUEL LEVEL DISPLAY OF SCANIA TRUCK

Figure 4.5: Technical Perspective

4.3.3 Requirement Perspective

A requirement perspective provides a construct for requirements, relation-ship between requirements. Figure 4.6 shows the relationrelation-ship between all the requirements involved in this case study. Following is a definition of the relationship derive requirement used in SysML,

”Derive requirement is a dependency relationship between two requirements in which a client requirement can be generated or inferred from the supplier requirements or additional design in-formation. Derived requirements may refine or restate a require-ment to improve stakeholder communications or to track design evolution[22].”

(39)

Figure 4.6: Requirement Perspective

4.3.4 Relation between Perspectives

Figure 4.7 illustrates the relationship between four perspectives. User func-tion 18 and C code are allocate to SESAMM and Byte code respectively in technical perspective.In addition, different function units in logical perspec-tive satisfy the requirements in requirement perspecperspec-tive.

Following is the definition of two terms that used to illustrate the rela-tionship between different perspectives,

”Allocate is a mapping between from one set of model elements (supplier) to another set of model elements (client). The map-ping is often performed as part of the design process to refine the design. Typical examples of allocation include allocation of functions to components, logical to physical components, flows to connectors, and software to hardware. The allocation of require-ments to components is generally accomplished using the SysML satisfy relationship[22].”

”Satisfy is a dependency relationship between a requirement and a model element that fulfills the requirement[22].”

(40)

(41)

TRUCK 4.4. FORMALIZE REQUIREMENT

4.4 Formalize Requirement

Since the textual requirements are not able to be processed by computer, the next step is to formalize these requirements into mathematical expressions or codes that can be proceed by computer. In our case study, there are four requirements need to be formalized, UFR18 1 and UFR18 4. Following are the formalized requirements modelica code,

For UFR18 1 if abs(t o t a l F u e l L e v e l - F u e l V o l u m e) > t o t a l F u e l L e v e l * 0 .05 t h e n 0 e l s e 1; For UFR18 4, l o w F u e l L e v e l W a r n i n g = if ( F u e l V o l u m e < T a n k S i z e * 0 .1) t h e n 1 e l s e 0;

After formalizing the requirement, the next step is to create the design model which will be verified against the requirements.

4.5 Modelica Model

4.5.1 Modelica Simulation Environment Dymola

After model all the relationships between different perspectives, the next step is to model it in Modelica. Their existing lots of different Modelica environment in market both commercial and free of charge. In this case study, Dymola is used as the simulation environment.

Dymola is short for Dynamic Modeling Laboratory, it is a commercial

Modelica environment from Dassault Syst`emes.1 _{Dymola supports}

hierar-chical model composition which means that it is able to include sub models

inside other models. This kind of composition helps user to decompose

complex models to simple ones in order to solve the complexity problem. In addition, Dymola supports multi-views modeling, graphs and coding. User can choose either drag and drop different blocks to the workspace or coding in the text view. These two different views are updated synchronously which is able to help users to avoid inconsistency problems.

4.5.2 Modelica Model

1_{Dassault Syst`}_{emes: Dassault Syst`}_{emes collaborative solutions foster social innovation,}

expanding possibilities for the virtual world to improve the real world. The group brings value to over 150,000 customers of all sizes, in all industries around the globe[?].

(42)

4.5. MODELICA MODEL

Figure 4.8: Modelica Structure

Level 1

Figure 4.9 shows the first level of Modelica Model, the workspace is divided into two different parts, user and requirement perspective and the technical perspective. In the user and requirement perspective there is the top level requirement UFR18 which set requirement to SESAMM. Verification block is used to verify the system design against requirement in the requirement verification.

In the technical perspective there are tank and SESAMM. SESAMM is processing the signal with noise because the tank is always shaking during driving. However, UFR set requirements based on the actual fuel volume in the tank. So tank provides these two signals, actual fuel volume and fuel level that measured by the sensor. At the bottom of the model is the interfaces for simulation with Simulink model.

(43)

TRUCK 4.5. MODELICA MODEL

Figure 4.9: Level 1 Structure of Modelica Model

Level 2

As we can see from Figure 5.1, in the second level, there are only technical perspectives in the model.ICL, COO and EMS Systems are connecting with each other through different CAN buses. All the cables including direct wires and CAN buses are represented by independent class. By doing this, it provides the possibility of introducing failures in the future in order to check how the system behaves against these failures.

(44)

4.5. MODELICA MODEL

Level 3

In the third level, there are Coordinator ECU and Sensor which placed inside the tank. A sensor measures the fuel level in the tank and send the voltage signal to Coordinator ECU. Together with the fuel consumption in the engine from EMS ECU, the Coordinator ECU estimates the fuel level in the tank by using Kalman Filter and send to ICL ECU through Yellow CAN Bus.

(45)

TRUCK 4.5. MODELICA MODEL

Level 4

In the logical and requirement perspective, there are two requirements AER 201 and AER 202 which are implemented in this level. In AER201, there is a switch to switch between background requirement or other requirement which derived from background requirement and verify the system design against different requirements. AER202 has the same structure to switch between different requirements.

In logical perspective, Simulink model is a realization of Allocation Ele-ment 201 and 202, the Dymola model is able to be compiled as an S-function in order to be used in Simulink. Verification block here can be used to ver-ify technical system against the Allocation Element requirement or Simulink model.

(46)

4.5. MODELICA MODEL

4.5.3 Dynamic Simulation

There already exists a Simulink model which is a realization of Allocation Elements. The next step is to comply the Modelica Model as S-Function and implement it in the existing Simulink model.Figure 5.1 shows the Simulink Model with Dymola interface. On the right hand side, four different blocks dealing with Input, Algorithm, Route and Output of the signal. The final output of the Simulink model is able to be plotted in the plot window of Dy-mola. After plotting, we can verify the system design against requirements by using the verification result indicators.

(47)

TRUCK 4.6. SYSTEM VERIFICATION AGAINST REQUIREMENT

logSignals Logsignals: on ModelParts: fuel/Inputs fuel/Algoritm Unit Delay1 z 1 Unit Delay z 1 RouteOuputs lowFuelLevelInd_str(in) reset_str(in) fuelLevelTot_str fuelVolume_str(in) fuel_params_inputBus_str(in) fuel_inputBus_str tankCapacity_str lowFuelLevelInd_str reset_str fuelVolume_str fuel_params_inputBus_str fuelLevelTot_out_str Outputs lowFuelLevelInd_str reset_str fuelVolume_str fuel_params_inputBus_str fuelLevelTot_out_str lowFuelLevelInd fuelLevelPercentage_Val_F32 Inputs fuelRate fuelLevel fuel_inputBus_str fuel_params_inputBus_str tankCapacity_str tankSizes_str Gain -K-DymolaBlock totalFuelVolume warning fuelRate fuelLevel single single Check model

BUILD THIS MODEL using a new instance of Matlab ApplSetup fuelDataDef Algoritm fuel_inputBus_str(in) fuel_params_inputBus_str(in) tankCapacity_str(in) tankSizes_str fuelLevelTot_out_str lowFuelLevelInd_str reset_str fuelLevelTot_str fuelVolume_str fuel_params_inputBus_str fuel_inputBus_str tankCapacity_str fuel_inputBus_str fuel_inputBus_str fuel_params_inputBus_str fuelVolume_str lowFuelLevelInd_str tankCapacity_str fuelLevelTot_str fuelVolume_str fuel_params_inputBus_str fuel_inputBus_str fuel_params_inputBus_str fuelLevelTot_out_str reset_str tankSizes_str tankCapacity_str reset_str lowFuelLevelInd_str

Figure 4.13: Simulink Model with Dymola Interface

4.6 System Verification against Requirement

All the simulation is based on the test scenario. Therefore, in our case study, we assume the truck is driving with constant speed and the fuel consumption is 30 liter/hour in the engine. In addition, the fuel level in tank is decreased from 20% of the tank capacity to 0%. Apart from this, the fuel level sensor in tank is based on a float shaking with the surface of fuel. A Random Number Generater could simulate the shaking of fuel surface in tank. The Modelica Code for Random number Generater can be found in Appendix A.

4.6.1 Test Scenario

After having designed the system, the next step is to create a verification scenario (Figure 4.14) in order to verify whether the designed system fulfills the requirements. For the fuel level display system, the verification scenario describes how the fuel level in the tank decreases with respect to time.

In this case study, a verification scenario describes the fuel level in the tank decreasing from 20% to 0% of the capacity of the tank. The verification scenario provides two inputs to the design model, Fuel level and Fuel Volume.

(48)

4.6. SYSTEM VERIFICATION AGAINST REQUIREMENT

Figure 4.14: Test Scenario

Fuel level represents the fuel level measured by the sensor which consists of a noise signal caused by the shaking of tank during driving. The fuel volume represents the ideal fuel volume in the tank. In Figure 4.15, the blue line represents the fuel level and the red line represents fuel volume. By using this verification scenario,UFR18 1 andUFR18 4 can be verified at the same time.

(49)

TRUCK 4.6. SYSTEM VERIFICATION AGAINST REQUIREMENT

gressively from 20% to 0%. The blue line shows the indicated fuel level from the Instrument Cluster System. Finally, the green line shows the re-quirement status. The status starts at 1 which means the rere-quirement is not violated until around 20000 seconds. From around 20000 seconds, the status changes to 0 which means that the requirement is violated. So the corre-sponding requirement UFR18 1 is not violated in the first 20000 seconds, then it violated until the end of the simulation 21600 seconds.

Figure 4.16: Simulink Model Verification Against User Function Require-ment 18: Displayed Fuel Level

Figure 4.17 shows the verification results of the Low Fuel Level Warning element. The blue line shows the indicated fuel level from Instrument Clus-ter System which decreases progressively from 20% to around 0%. The red line shows the threshold at which the low fuel level warning must be active. The black status line illustrates that the requirement UFR18 4 is violated during 10541 second to 10776 second.

(50)

4.6. SYSTEM VERIFICATION AGAINST REQUIREMENT

Figure 4.17: Simulink Model Verification Against User Function Require-ment 18: Low Fuel Level Warning

(51)

Chapter 5 Conclusion

• This four perspectives structure defined in this thesis can provide one solution for traceability and dependability in the system design phase. The traceability between different perspectives help engineers have a clear picture of the whole system. In addition, the traceability be-tween logical perspective to the technical perspective indicates how functions are allocated to the physical system. It provides one solu-tion for analysis complex system and helps engineers to think about the whole system before digging into the details.

However, there are also some drawbacks. Some semantics in the lan-guage cause extra discussion among engineers. It could lead to mis-understanding between engineers and raise lots of discussion.

• This case study illustrates the approach to formalizing requirements for document-based format, and generating verification scenarios to

test whether the system fulfills these requirements. By using this

approach, it is able to verify one requirement against several alter-native system designs or one system design against several require-ments, it shortens the time in the verification process. In addition, compare with the traditional verification process, model based system design against requirement verification is more reliable, cost-effective and time-saving.

• During this thesis work, Requirement Document Deficiency problem also raised. Following is one of the example,

(52)

CHAPTER 5. CONCLUSION

(53)

CHAPTER 5. CONCLUSION

The following figure shows the Simulink Model and its corresponding requirement documents Allocation Element Requirement 202. The Simulink Model shows that if the tank size is below 900 liter, the threshold of low fuel level warning should be 10%. However, in the Allocation Element Requirement 202 document, it said that if the tank size is below or equal 900 liter, the threshold is 10%.

– The output of AE202 is send to Yellow CAN Bus, however, from Allocation Element 202 requirement documents, the the output of AER 202 background requirement is send to ICL directly. – Fuel level and fuel volume interchangeably. From requirement

document AER201 and AER202, Fuel Level reference to volume unit Liter which could confuse the reader.

– The link between AE201 to Real-Time Data Base is missing from the document Function Allocation Description.

Since the systems are becoming more and more complex, it is hard to go through the Simulink model to understand everything. Most people are more comfortable with reading the requirement documents. This deficiency of requirement documents could bring potential risk to the system in the future.

(54)

Chapter 6 Future Work

For this project, there are some areas that could be improved in the future,

• The methodology for requirement verification provides one solution. It would be of interest to test in other Modelica environments which support SysML notation in modeling. Dymola has strong ability for simulation, however, a modeling environment supports SysML nota-tion would help stakeholder understand to all the system artifacts.

• Another possibility would be test different test scenarios. In our case study, the test scenario is only assumed to be 20% to 0% without any stop or change of speed during driving because of the capacity of com-puter. It could be more accurate if the test scenario uses the raw data measured from Scania truck includes full range of fuel consumption from 100% to 0%. In addition, further refinement of the model could be able to test more requirements in the verification phase.

(55)

Bibliography

[1] IEEE Standard for the Application and Management of the Systems Engineering Process, 2005. 3.1.35.

[2] NASA Systems Engineering Handbook. National Aeronautics and Space Administration, December 2007.

[3] ISO 26262-1:2011. Road vehicles : Functional safety - Part 1: Vocabu-lary. ISO, first edition edition, 2011. 2011-11-15.

[4] Modelica Association. Modelica-a unified object-oriented language for physical systems modeling language specification. https://modelica. org/documents/ModelicaSpec32.pdf, 2010.

[5] Wolter J.Fabrycky Benjamin S.Blanchard. Systems Engineering and Analysis. Prentice Hall, 4th edition edition, 2005.

[6] Albert Benveniste, Werner Damm, Alberto Sangiovanni-Vincentelli, Dejan Nickovic, Roberto Passerone, and Philipp Reinkemeier. Con-tracts for the design of embedded systems part i: Methodology and use cases. Technical report.

[7] Bjorn Cole, Chris Delp, and Kenny Donahue. Piloting model based engineering techniques for spacecraft concepts in early formulation. IN-COSE, 2010.

[8] Jonas Ed´en and Anna Selmarker. Funktionsbeskrivning. Scania

Docu-ment, 2007.

[9] Carolin Erlandsson. User function requirements uf18 fuel level display. Scania Document.

[10] Xavier Franch. Systematic formulation of non-functional characteris-tics of software. In Requirements Engineering, 1998. Proceedings. 1998 Third International Conference on Requirements Engineering (ICRE ’98), April 6-10, 1998, Colorado Springs, CO, USA, pages 174 –181, 6-10.

(56)

BIBLIOGRAPHY BIBLIOGRAPHY

[11] Sanford Friedenthal, Alan Moore, and Rick Steiner. A Practical Guide to SysML: The Systems Modeling Language. The MK/OMG Press. Elsevier/Morgan Kaufmann, 2008.

[12] Peter Fritzson. Principles of Object-Oriented Modeling and Simulation with Modelica 2.1. Wiley-IEEE Computer Society Pr, 2003.

[13] Martin Glinz. On non-functional requirements. 15th IEEE Interna-tional Requirements Engineering Conference, RE 2007, October 15-19th, 2007, New Delhi, India.

[14] Lind Hans. The sesamm concept. PD1422538, 2003.

[15] IHS Global Insight. Resistance is futile electronics are on the rise

elec-tronic control units and communication protocols. http://www.ihs.

com/images/Electronics.pdf, April 2009.

[16] Feng Liang, Wladimir Schamai, Olena Rogovchenko, Sara Sadeghi, Mattias Nyberg, and Peter Fritzson. Model-based requirement veri-fication : A case study. 9th International Modelica Conference (Mod-elica’2012), Munich, Germany, Sept.3-5, 2012.

[17] Anders Lundstr¨om and Leif ¨Ostling. A model for success, 2010. Scania

Document.

[18] International Council on Systems Engineering INCOSE. System Engi-neering Vision 2020. ISO, p15 edition, 2007. September, 2007. [19] ScaniaWiki. Sesamm model concept. http://wiki.inline.scania.com/

wiki/SESAMM model concept, 2011. [cited: 2012-01-25 ].

[20] Wladimir Schamai, Peter Fritzson, Christiaan J. J. Paredis, and Philipp Helle. ModelicaML value bindings for automated model composition. Symposium on Theory of Modeling and Simulation (TMS/DEVS 2012). Orlando, Florida, USA, March 26-29, 2012.

[21] Wladimir Schamai, Philipp Helle, Peter Fritzson, and Christiaan J. J. Paredis. Virtual verification of system designs against system require-ments. 3rd International Workshop on Model Based Architecting and Construction of Embedded Systems (ACES’2010). In conjunction with MODELS’2010. Oslo, Norway, Oct 4, 2010.

[22] SysML Merge Team (SMT). Sysml glossary. http://www.sysml.org/ docs/specs/SysML-v1-Glossary-06-03-04.pdf, April 2006.

(57)

BIBLIOGRAPHY BIBLIOGRAPHY

[25] Peter Walleb¨ack. Allocation element requirement low fuel level warning

aer202. Scania Document, October 2010.

[26] Wikipedia. Electronic control unit. http://en.wikipedia.org/wiki/

(58)

Appendix A

Uniform Random Number

Generater

b l o c k R a n d o m N u m b e r G e n e r a t o r " G e n e r a t e R a n d o m N o i s e S i g n a l " e x t e n d s M o d e l i c a . B l o c k s . I n t e r f a c e s . B l o c k I c o n ; c o n s t a n t R e a l a=7 ^ 5 ; c o n s t a n t R e a l b=0; c o n s t a n t R e a l m=2 ^ 3 1-1; i m p o r t SI = M o d e l i c a . S I u n i t s ; p a r a m e t e r S I . T i m e Ts=0 . 0 0 0 1 " T i m e s t e p is 0 . 0 0 0 1 s e c o n d "; p a r a m e t e r R e a l s e e d=10 " S e e d of R a n d o m G e n e r a t o r "; d i s c r e t e R e a l max " M a x i m u m n u m b e r w h e n y are g e n e r a t e d "; d i s c r e t e R e a l n ; p a r a m e t e r R e a l r a t i o=0 .2 " W h e n r a t i o is 1 m e a n s n o r m a l d i s t r i b u t i o n f r o m 0 to 1 "; p a r a m e t e r R e a l o f f s e t=0 .2 " O f f s e t of the g e n e r a t e d s i g n a l "; M o d e l i c a . B l o c k s . I n t e r f a c e s . R e a l O u t p u t y a n n o t a t i o n (P l a c e m e n t(t r a n s f o r m a t i o n(e x t e n t= { {96 ,-10},{116 ,10} } ) ) ); i n i t i a l e q u a t i o n pre(y) = 0; pre(max) = 1; pre(n) = s e e d ; e q u a t i o n w h e n {i n i t i a l( ), s a m p l e(0 , Ts) } t h e n n = rem( (a*pre(n) +b), m);

(59)

APPENDIX A. UNIFORM RANDOM NUMBER GENERATER end w h e n; a n n o t a t i o n (I c o n(g r a p h i c s= {T e x t( e x t e n t= { { -110 ,40},{110 ,-40} }, l i n e C o l o r= {0 ,0 ,255}, t e x t S t r i n g=" RNG ") } ) ); end R a n d o m N u m b e r G e n e r a t o r ;

(60)

Appendix B

Requirement Selected

from Scania Documents

B.1 User Function Requirement 18

The intended functionality of UF18 Fuel level display is to support the driver to not run out of fuel. If the driver does not observe the fuel level gauge frequently enough to notice the fuel level is becoming dangerously low, a complementary warning is helpful to catch the drivers attention when a critical limit is reached. Drivers may also be expecting a warning if they are used to drive competitors’ vehicles, since a warning system seems to be common.[9]

UFR 18 1 The displayed fuel level shall not deviate more than

5% from the total actual remaining fuel volume that is collectable from the tank(s).

UFR 18 4 The limit for activating low fuel level warning shall

be 10% for a total tank size below 900 litres.

B.2 Allocation Element Requirement 201

In Allocation Element 201 is used for estimate the percentage of fuel in tank compared with total volume. From Scania technical document Allo-cation Element requirement 201, following requirements are implement in modelica[24],

(61)

APPENDIX B. REQUIREMENT SELECTED FROM SCANIA

DOCUMENTS B.2. ALLOCATION ELEMENT REQUIREMENT 201

AER 201 6 The fuel level shall be able to reach all values from

0% to 100%

AER 201 9 If the truck has one fuel level sensor connected, its

voltage value should be transformed into a corre-sponding volume value in litres. The volume value should be low pass filtered before set to fuelLevel

sig-nal (ys). The filter is given by with (Cpre = 0.99).

AER 201 11 totalFuelLevel should be the output of a filter that

includes information from both fuelLevel and fuel-Rate to achieve a stable signal. the filter should be implemented with a Kalman algorithm given by with

the feedback gain K = 1.0786 × 10−5.

AER 201 12 The start-up state for the totalFuelLevel estimated

should be the state saved from last shutdown if the stored value and fuelLevel doesn’t differ with more than 10% of the total volume or if fuelLevel is above

90%2 _{of the useable tank capacity.}

where:

ys= filtered fuel level [m]

Ts= sampletime [s]

xin= measured fuel level [m]

xstart=

(

ys(t), | ys− ˆxold|> 0.1Xtotor ys> 0.9Xtot

ˆ xold, otherwise (B.2) ˆ x(t + Ts) = (

xstart, during start − up

ˆ

x(t) − Tsu(t) + K(ys(t) − ˆx(t)), other

(B.3)

y(t) = F (ˆx(t)) (B.4)

where:

ys= measured fuel level [m3]

ˆ

xold= fuel level at last shutdown [m3]

Xtot= total fuel volume [m3]

(62)

B.3. ALLOCATION ELEMENT REQUIREMENT 202

APPENDIX B. REQUIREMENT SELECTED FROM SCANIA DOCUMENTS

u = fuel consumption [m3_/s]

ˆ

x = estimated fuel level [m3_]

K = feedback gain [−]

F (x) = function converting m3 _{to corresponding %}

y = total fuel level [%] xstart = start state [m3]

B.3 Allocation Element Requirement 202

This AER202 contains information about the allocation element that han-dles the low fuel level warning implemented in COO in Scania vehicles[25],

AER 202 2 The lowFuelLevelWarning should be set to 1 (true)

when input totalFuelLevel is below a predefined level. The level should be 10% for tank size equal or below 900 liters and 7% for tank sizes larger than 900 liters

(63)

Avdelning, Institution

Division, Department

IDA,

Dept. of Computer and Information Science 581 83 Link¨oping Datum Date 2012-08-30 Spr˚ak Language D Svenska/Swedish × D Engelska/English D Rapporttyp Report category D Licentiatavhandling × D Examensarbete D C-uppsats D D-uppsats D O¨ vrig rapport D ISBN LIU-IDA/LITH-EX-A–12/045–SE ISRN LiU-Tek-Lic–PUBYEAR:2012

Serietitel och serienummer ISSN

Title of series, numbering _-

Link¨oping Studies in Science and Technology Thesis No.

URL f¨or elektronisk version

http://XXX

Titel

Title

Modeling in Modelica and SysML of System Engineering at Scania Applied to Fuel Level Display

F¨orfattare

Author

Feng Liang

Sammanfattning

Abstract

The main objective of this thesis is to introduce a four perspectives structure in order to provide one solution for traceability and dependability in the system design phase. The traceability between different perspectives help engineers have a clear picture of the whole system before goes to the real implementation.

Fuel Level Display system from Scania Truck is used to undertake as a case study to offer insights of the approach. A four perspectives structure is made in the first place in order to analysis traceability between different viewpoints. After

implementing the Fuel Level Display system in Modelica, a verification scenario is specified to perform a complete requirement verification process for system design against requirements.

Modeling in Modelica and SysML of System Engineering at Scania Applied to Fuel Level Display

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Modeling in Modelica and SysML

of System Engineering at Scania

Applied to Fuel Level Display

by

Feng Liang

LIU-IDA/LITH-EX-A--12/045—SE

2012-08-30

Final Thesis

Modeling in Modelica and SysML

of Engineering of Systems at Scania

Applied to Fuel Level Display

by

Feng Liang

LIU-IDA/LITH-EX-A--12/045—SE

2012-08-30

Supervisor: Olena Rogovchenko, IDA, LiTH

Mattias Nyberg, Scania CV AB

Examiner: Peter Fritzson, IDA, LiTH

Abstract

Acknowledgements

Contents

List of Figures

Glossary

Chapter 1

Introduction

1.1

About Scania

1.2

Background

1.3

SysML

1.4

Modelica

1.5

Virtual Verification of Designs against

Re-quirements(vVDR)

1.6

Goal and Scope

Chapter 2

Methodology of

Requirement Verification

2.1

Requirement Selection

2.1.1

Requirement Classification

2.2

Formalizing Derived Requirements

2.3

System Design

2.4

Requirement Verification

Chapter 3

Technical and Functional

Architecture in Scania

3.1

Technical architectures in Scania:SESAMM

3.1.1

ECU System

3.1.2

DEC System

3.2

Functional Architecture

3.2.1

Allocation Elements AEs

3.2.2

Function Variables FVs

3.2.3

User Functions UFs

Chapter 4

Case Study: Fuel Level

Display of Scania Truck

4.1

Introduction of Fuel level Display System

4.1.1

Technical Architecture of Fuel Level System

4.1.2