Appendix C. XSD and XML documents
The full XSD model derived from the UML model in Figure 17 is shown below.
<?xml version = "1.0" encoding = "utf-8"?>
<xsd:schema elementFormDefault = "qualified" xmlns:xs =
"http://www.w3.org/2001/XMLSchema">
<xsd:element name = "jaguarlandrover" type = "Company" />
<xsd:complexType name = "Company">
<xsd:sequence>
<xsd:element name = "vehicle" type = "Vehicle" minOccurs =
"1" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name = "Vehicle">
<xs:sequence>
<xs:element name = "colour" type = "xsd:string" minOccurs = "1" maxOccurs = "1"/>
<xs:element name = "transmissionType" type = "xsd:string"
minOccurs = "1" maxOccurs = "1"/>
<xs:element name = "body" type = "Body" minOccurs = "1"
maxOccurs = "2"/>
<xs:element name = "engine" type = "Engine" minOccurs =
"1" maxOccurs = "unbounded"/>
</xs:sequence>
<xs:attribute name = "vehicleId" type = "xsd:string"/>
</xsd:complexType>
<xsd:complexType name = "Body">
<xsd:sequence>
<xsd:element name = "numberOfDoors" type = "xsd:integer"
minOccurs = "1" maxOccurs = "unbounded"/>
</xsd:sequence>
<xs:attribute name = "bodyType" type = "xsd:string"/>
</xsd:complexType>
<xsd:complexType name = "Engine">
<xsd:sequence>
<xsd:element name = "fuelType" type = "xsd:string"
minOccurs = "1" maxOccurs = "1"/>
</xsd:sequence>
<xs:attribute name = "engineSize" type = "xsd:integer"/>
</xsd:complexType>
<xsd:complexType name = "vehicleType">
<xsd:complexContent>
<xsd:extension base = "Vehicle">
<xsd:sequence>
<xsd:element name = "brandType" type = "DriveType"
minOccurs = "1" maxOccurs = "1"/>
<xsd:element name = "wheelDrive" type =
"xsd:integer" minOccurs = "1" maxOccurs = "1"/>
<xsd:element name = "driveType" type = "DriveType"
minOccurs = "1" maxOccurs = "1"/>
<xs:attribute name = "vehicleBrand" type = "xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType>
<xsd:complexType name = "DriveType">
<xsd:complexContent>
<xsd:extension base = "VehicleType">
<xsd:sequence>
<xsd:element name = "driveType" type =
"xsd:string" minOccurs = "1" maxOccurs = "1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType> </xsd:schema>
The full XML document derived from the UML and XSD is shown below.
<?xml version = "1.0" encoding = "UTF-8" ?> <jaguarlandrover
xmlns = "http://dvi.org/DVI"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance">
<vehicle vehicleId = "ER234678">
<colour>White</colour>
<transmissionType>Auto</transmissionType>
<body bodyType = "Aluminium">
<numberOfDoors>5</numberOfDoors>
</body>
<engine engineSize = "3">
<fuelType>Diesel</fuelType>
</engine>
</vehicle>
<vehicle vehicleId = "XJ234678" vehicleBrand= "Jaguar" xsi:type =
"VehicleType">
<colour>Red</colour>
<transmissionType>Manual</transmissionType>
<body bodyType = "Aluminium">
<numberOfDoors>5</numberOfDoors>
</body>
<engine engineSize = "3">
<fuelType>Diesel</fuelType>
</engine>
<brandType>XJ</brandType>
<wheelDrive>2</wheelDrive>
<driveType>RightHandDrive</driveType>
</vehicle> </jaguarlandrover>
Appendix D. Attributes used for the development of SDVM
Table 28 shows the list of attributes used for the design of the new Standardised Design Verification Method (SDVM).
Test Specification Attributes
Vehicle network I/O interfaces • CAN • LIN • MOST • Ethernet
• Other (this may include, USB, hands free phone connectivity, iPod, voice, Bluetooth, DVD, dual view touch screen, AM/FM, 3G, 4G)
Vehicle hardware I/O interfaces
• Digital I/O such as switch inputs and outputs (low/high side driver) • Analogue I/O such as resistive voltage inputs and voltage control outputs • Pulse Width Modulation (PWM), a common type of digital I/O often used in the
automotive industry. A typical application that uses PWM is window control
ECU specific monitoring parameters
• Read of Electrically Erasable Programmable Read-Only Memory (EEPROM). A typical application that uses EEPROM read is vehicle seat position control • Read of calibration parameters such as vehicle engine maps
• Other various ECU software parameters
• Read and write of car configuration. It is used to configure a vehicle for different markets (i.e. left or right hand drive)
• Vehicle diagnostics. Mainly used to put ECU into programing mode or read fault codes after a cycle of tests
Type of validation
• ON/OFF. An ON/OFF input signal that causes the output to change state. This is a common attribute for body, comfort and climate systems
• Function-based. The input signal is a function such as ramp up and rump down. This is a common attribute for chassis and powertrain systems
• IF/ELSE, the input or output signal is subject to an IF and ELSE condition. This is a common attribute for infotainment systems
• FOR LOOP the input or output signal is subject to a FOR LOOP condition. This is a common attribute for infotainment systems
• Truth table. The input and output signals are subject to a truth table. This is a common attribute for infotainment systems
• Lookup table. The input and output signals are subject to a lookup table. This is a common attribute for transmission systems
Control logic of the embedded software under test
• State control logic. This is a common attribute for body, comfort and climate systems • Continuous control logic. This is a common attribute for chassis and powertrain
systems
• Event driven control logic. This is a common attribute for infotainment and HMI systems
Test target or test platform
• Offline PC-based • Real-time
Test method • Data are confidential and therefore are only available in Submission 4 Table 28. List of attributes used for the design of SDVM.
Appendix E. Supported conditions and branches within the SDVM
Table 29 provides full description of the supported conditions and branches within the SDVM.
Condition/ Branch
SDVM Template Semi-formal Notation -
Example Description
For Loop LOOP(5|) Loops five times the test case
While Loop LOOP(PowerModeSignal>0) Loops until the condition is satisfied If Else CHECKIF(PowerModeSignal==0) Proceed If condition is satisfied
Goto GOTO(LOC_TEST_ID_1) Go to test case with ID 1
Table 29. Description of condition and branches.
An example of a condition/branch is given as follows:
Test case condition using informal specification:
Check if vehicle signal called “PowerMode_MS” is greater than 6 (6 = Ignition). If this condition is true then move to test case with ID 4.
Test case condition in condition/braches section using semi-formal specification: CHECKIF(PowerMode_MS>6) {GOTO(TEST_CASE_ID_4)}
Appendix F. FURPS+ model
Table 30 shows the definition of FURPS+ requirements. Functionality is the only type of functional requirement. Functionality is referring to what the customer wants and as a result the main features of the product. In this research Functionality refers to a set of requirements to deliver the main features of PITS. The remaining types of requirements in the FURPS+ model are of non-functional type.
FURPS Meaning Type
Functionality Main product features. Functional
Usability User interface, accessibility, aesthetics and consistency.
Non- functional
Reliability Availability, accuracy and recovery.
Performance Throughput, response time, recovery time and start-up
time.
Supportability Testability, adaptability, maintainability, compatibility,
configurability, installability and scalability.
+ Meaning
Design requirements Design constraints.
Implementation
requirements Coding or construction constraints.
Interface requirements Interaction with an external item.
Physical requirements Physical constraint imposed on the hardware.
Appendix G. Summary of evaluation results