Interfacing MOST networks from Pantera - Com Hemweb.comhem.se/~u37600264/files/exjobb_cth.pdf ·...

Interfacing MOST networks from Pantera

THOMAS MOSSBERG JAKOB SVENSSON Master's Thesis Computer Science and Engineering Program CHALMERS UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering Division of Computer Engineering Göteborg 2006

All rights reserved. This publication is protected by law in accordance with “Lagen om Upphovsrätt, 1960:729”. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the authors.

© Thomas Mossberg, Jakob Svensson, Göteborg 2006.


Abstract The objective of this thesis is to add support for interfacing MOST networks from Pantera; an existing diagnosis and test automation tool supporting several network types, which is developed by Movimento. An understanding of the desired MOST functionality was achieved by evaluating the existing tools: Optolyzer and Pantera along with interviews of their users; where Optolyzer is an analyzing and simulation tool for MOST networks provided by Oasis. In order to communicate with the devices on the network we were besides the need of implementing new functionality dependable of using the existing PumaMOST device; an electronic diagnostic and analytical hardware tool used to connect Pantera to the network. Due to the lack of support for sending and receiving MOST control messages in this device it was necessary to modify its existing interface as well as its embedded software. Finally a test implementation was realized and verified before this report was written.

Sammanfattning Syftet med detta examensarbete är att införa funktionalitet som möjliggör kommunikation med MOST nätverk från diagnos och testautomatiserings-verktyget Pantera vilket stöder flertalet olika typer av nätverk och som är utvecklat av Movimento. Genom att utvärdera de existerande verktygen Optolyzer och Pantera samt intervjua dess användare så bildade vi oss en uppfattning om vilken funtionalitet som var önskvärd; där Optolyzer är ett analys och simulationsverktyg för MOST nätverk tillandahållet av Oasis. För att möjliggöra kommunikation med MOST enheter från Pantera så krävdes förutom ny funktionalitet även att vi använda oss utav hårdvaran PumaMOST; ett elektroniskt diagnos och analysverktyg som används för att koppla ihop Pantera med nätverket. Eftersom denna hårdvara saknade stöd för att kunna skicka och ta emot kontrollmeddelanden så gjordes en modifiering av dess existerande interface samt inbyggda mjukvara. Slutligen så gjordes en testimplementering av vald funktionalitet, följt av verifiering och skrivandet av denna rapport.

i


Preface This report is a master thesis work performed at Movimento in Gothenburg by Thomas Mossberg and Jakob Svensson with Peter Öhman as our examiner. It is a part of a master’s degree in Computer Science at Chalmers University of Technology in Gothenburg, Sweden. We wish to express our gratitude to those at Movimento who have helped us making this thesis possible. Special thanks to our supervisor Marcus Rimén, Magnus Fogelberg and Jonas Engström whom all conduced to profitable discussions.

ii


Table of Contents TABLE OF CONTENTS...................................................................................................................................... 1 1 INTRODUCTION.............................................................................................................................................. 3

1.1 BACKGROUND............................................................................................................................................... 3 1.2 PURPOSE ....................................................................................................................................................... 3 1.3 SCOPE............................................................................................................................................................ 4

2 MOST TECHNOLOGY.................................................................................................................................... 5 2.1 BACKGROUND............................................................................................................................................... 5 2.2 OVERVIEW .................................................................................................................................................... 6 2.3 CHANNELS .................................................................................................................................................... 7 2.4 FRAMES......................................................................................................................................................... 7 2.5 CONTROL MESSAGES .................................................................................................................................... 8

2.5.1 Function Block...................................................................................................................................... 8 2.5.2 Instance ................................................................................................................................................ 9 2.5.3 Function................................................................................................................................................ 9 2.5.4 Operation Type................................................................................................................................... 10 2.5.5 Addressing .......................................................................................................................................... 11 2.5.6 Network Master .................................................................................................................................. 12 2.5.7 Central Register.................................................................................................................................. 12 2.5.8 Function Catalogue ............................................................................................................................ 12

3 EVALUATION ................................................................................................................................................ 14 3.1 OPTOLYZER AND OPTOLYZER4MOST ........................................................................................................ 14

3.1.1 Overview............................................................................................................................................. 14 3.2 PANTERA..................................................................................................................................................... 15

3.2.1 Overview............................................................................................................................................. 15 3.3 INTERVIEWS ................................................................................................................................................ 18 3.4 DISCUSSION................................................................................................................................................. 18

4 REQUIREMENTS........................................................................................................................................... 24 4.1 FUNCTIONAL ............................................................................................................................................... 24 4.2 E-PACKET ................................................................................................................................................... 30

4.2.1 sendMessage....................................................................................................................................... 30 4.2.2 sendMessageToGrp ............................................................................................................................ 30 4.2.3 sendMessageToAll .............................................................................................................................. 31 4.2.4 setProperty ......................................................................................................................................... 31 4.2.5 getProperty ......................................................................................................................................... 31

5 PUMAMOST.................................................................................................................................................... 32 6 ANALYSIS ....................................................................................................................................................... 32

6.1 CONCEPTS ................................................................................................................................................... 33 7 INTERFACES.................................................................................................................................................. 35

7.1 RP1210 ....................................................................................................................................................... 35 7.1.1 RP1210_ClientConnect ...................................................................................................................... 35 7.1.2 RP1210_SendCommand ..................................................................................................................... 35 7.1.3 RP1210_SendMessage........................................................................................................................ 35 7.1.4 RP1210_ReadMessage ....................................................................................................................... 35 7.1.5 RP1210_ReadMessage ....................................................................................................................... 36 7.1.6 RP1210_ReadMessage ....................................................................................................................... 36 7.1.7 RP1210_ClientDisconnect.................................................................................................................. 36

7.2 PUMAMOST ............................................................................................................................................... 36 1


7.2.1 MOST Filter Message Frame ............................................................................................................. 36 7.2.2 MOST Control Message Frame.......................................................................................................... 37 7.2.3 MOST Acknowledge Message Frame................................................................................................. 37 7.2.4 MOST Error Message Frame ............................................................................................................. 37 7.2.5 MOST Interface Description .............................................................................................................. 38

8 DESIGN ............................................................................................................................................................ 39 8.1 ARCHITECTURE ........................................................................................................................................... 39 8.2 FUNCTION CATALOGUE............................................................................................................................... 39 8.3 SIGNALS ...................................................................................................................................................... 41

8.3.1 Base Signals........................................................................................................................................ 41 8.3.2 User Signals........................................................................................................................................ 42

8.4 CLIENT ........................................................................................................................................................ 43 8.4.1 Class diagram..................................................................................................................................... 43 8.4.2 Classes................................................................................................................................................ 44

8.5 SERVER ....................................................................................................................................................... 45 8.5.1 Class diagram..................................................................................................................................... 45 8.5.2 Classes................................................................................................................................................ 46 8.5.3 Run a test ............................................................................................................................................ 46 8.5.4 Send MOST Control Messages ........................................................................................................... 49 8.5.5 Read MOST Control Messages........................................................................................................... 50

9 IMPLEMENTATION ..................................................................................................................................... 53 9.1 ENVIRONMENT ............................................................................................................................................ 53 9.1 REALIZATION .............................................................................................................................................. 53 9.3 RESULTS...................................................................................................................................................... 53

9.3.1 MOST Device Configuration Dialog .................................................................................................. 54 9.3.2 MOST Port Configuration Form ........................................................................................................ 55 9.3.3 MOST Function Catalogue Form....................................................................................................... 56

10 TEST ............................................................................................................................................................... 57 10.1 ENVIRONMENT .......................................................................................................................................... 57 10.2 METHODOLOGY ........................................................................................................................................ 57 10.3 RESULTS.................................................................................................................................................... 58

11 IMPROVEMENTS ........................................................................................................................................ 58 12 CONCLUSIONS ............................................................................................................................................ 59 GLOSSARY......................................................................................................................................................... 60 REFERENCES.................................................................................................................................................... 63 Appendix A: Use Cases Appendix B: GUI Prototypes Appendix C: System Test Specification Appendix D: PanteraTM MOST Device Manual

2


1 Introduction Advanced electronic systems and communication networks play an increasingly important role in the operation of modern vehicles [1]. They provide enhanced safety features, control of sophisticated powertrain and chassis systems as well as infotainment and telematics capabilities. A network supporting infotainment capabilities is the Media Oriented System Transport (MOST) network; a fundamental backbone network for all digital multimedia systems in automobiles and consumer electronics.

1.1 Background Movimento Group provides the tools and expertise required for efficient design, development, manufacture, service and maintenance of communication networks used in modern vehicles. The diagnosis and test automation tool Pantera is evolved at the department of software development. It has support for several network types, such as: Controller Area Network (CAN), Recommended Standard-232 (RS232), Ethernet, and the most common electrical Input/Output (I/O) signal types; e.g. analogue, digital and pulse modulated signals. In a near future there is a need of interfacing the infotainment bus (MOST) from Pantera.

1.2 Purpose The purpose of this thesis is to add functionality for interfacing of MOST networks from Pantera and it consists of the following four parts:

1. First an evaluation will be conducted for the existing MOST tool (Optolyzer) in order to discover the users’ needs. The result will lay the foundation for how the MOST support should be implemented in Pantera on a System level.

2. Secondly the existing MOST interface between Pantera (software application) and the PumaMOST device (hardware) will be analyzed. It will address those modifications that have to be done in order to support the suggested MOST functionality

3. Thereafter follows a test implementation in Pantera, using C++ combined with Graphic User Interface (GUI) programming in Borland CBuilder and a verification of its new MOST functionality.

4. Finally the thesis will be written. .

3


1.3 Scope The final thesis consists of a written report (this report), the implementation and an oral presentation. The scope was estimated to be suitable for two E-, D- or F- students of technology during twenty weeks, were the time consumption for each part described in section 1.2 is divided as follows

• Four weeks for part one • Three weeks for part two • Nine weeks for part three • Four weeks for part four

The work was performed at the Gothenburg office located in Gårda and the supervisor has been Marcus Rimén, working as a Chief Executive Officer (CEO) at Movimento.

4


2 MOST Technology

2.1 Background The number of electronic devices and various multimedia peripherals in modern cars are growing rapidly. It would require a complex wiring harness with complex connectors to interconnect all these peripherals with traditional copper wire. Such a traditional analogue wire harness is costly, heavy and space consuming [2]. Using copper cable to connect a Compact Disc (CD) changer in the trunk of a car means that left and right signal cables plus a multi-wire control bus must be routed from the radio to the trunk. Done this way, a simple addition of one peripheral is costly and complicated. The bundle of copper wires running through the car becomes more and more voluminous, which adds weight and complexity to the automobile (see figure 1). Some modern cars already have several kilometres of wire running through them.

Figure 1: An outline of a car with a bundle of copper wires

running through it The increasing number of peripherals and the more sophisticated devices needs a system to control the interaction between the individual devices. Examples are the Global Position System (GPS) navigation system that needs to work in conjunction with a security system to locate a stolen car, or the car telephone which needs to interact with the stereo to mute when a call is requested or received. Moreover, the transport of high volumes of Streaming Data like high quality audio and video, and Packet Data like web pages, calls for more bandwidth. The traditional copper wiring systems do not match these future needs. Therefore the MOST System has been developed by and for the automotive industry. The MOST network topology is of ring-structure using a Polymer Optical Fibre (POF) to connect the devices (see figure 2). All signals are transported on one physical media and all data are available everywhere in the network. The benefits from this are that there have to be fewer cables drawn, which in turn reduces weight, cost and the complexity of the car. Because of the use of optical fibre there is no longer any need for concerning about Electromagnetic Interference (EMI). 5


Figure 2: An outline of a car with a MOST network,

connecting its devices

2.2 Overview MOST is a plug-and-play system with self-identifying devices and self-initialization. Because of the properties of MOST and the structure of the network’s topology, devices can be dynamically attached, removed or re-configured. Devices can be developed independently and then be networked together using standard hardware and software interfaces. The MOST network is a synchronous network which implies the presence of a timing master, that supplies a clock to which all other devices synchronize their operation to [3]. This technology eliminates the need for buffering and sample rate conversion so that very simple and inexpensive devices can be connected. The technology is similar to what the public switched telephone network uses. There are data channels and control channels defined. The control channels are used to set up what data channels the sender and receiver are to use. Once the connection is established, data can flow continuously and no further processing of packet information is required. This is the optimum mechanism for delivering streaming data (information that flows continuously). Computer based data, such as internet traffic or information from a navigation system, is typically sent in short bursts and is often going to many different places. MOST has defined efficient mechanisms for sending asynchronous packet based data. The control channel permits devices to send control messages while the data channels are in use so all devices can cleanly start up and shut down the data they are using. Just as important as the hardware, system software and Application Program Interfaces (API) are crucial to insure that devices from different manufacturers can interact with each other. The APIs need to be object oriented so applications can concentrate on the functions they provide. They need to be able to control all the features that devices provide on the network, whether from Audio/Video (A/V) equipment, GPS navigation systems, telephones or telematics systems. The MOST Specification encompasses both the hardware and the software required to implement a multimedia network. MOST defines all seven layers of the Open System Interconnection (OSI) reference model (see figure 3) so that a designer who develop an application can concentrate on the functions that affect the end user rather than the complexities of the underlying network. All MOST devices have been designed using this API to assure compatibility.

6


Figure 3: Figure showing the seven OSI layers

2.3 Channels A MOST network defines two types of channels: the data- and the control channel. The data channel is furthermore divided into an asynchronous and synchronous channel. The asynchronous channel is mainly used for transmitting data with large block size and high demands for bandwidth in a burst like manner (graphics, some picture formats and navigation maps) [4]. The synchronous channel on the other hand is used for continuous data streams that demand high bandwidths. Since the data channels are out of the scope for this thesis they are repudiated and our interest is instead dedicated to the control channel. The Control Channel is generally specified for event-oriented transmissions at low bandwidth and short package length. In other words: it is usable for: setting what data channels the sender and receiver are to use, control the network capabilities and execute commands on the devices connected to the network. A few examples of commands would be: the start or stop of the CD player and setting or getting the climate controls desired temperature value. The packets are transported to addresses with Cyclic Redundancy Check (CRC). It also has an Acknowledged (ACK)/Not Acknowledged (NAK) mechanism with automatic retry.

2.4 Frames The basic structure for data transfer in a MOST System is the MOST frame shown in figure 4. Each frame consists of 64 bytes where 60 bytes are available for transporting Stream and Packet Data. Two additional bytes are used for transporting the Control Data [2].

Figure 4: A picture that visualizes a MOST frame.

7

Interfacing MOST networks from Pantera For control data transfer, the MOST system provides a block structure where each block consists of 16 MOST frames with 64 bytes each. A MOST control frame (see figure 5) has a size of 32 bytes implying that it requires 16 MOST frames to send a control message.

Figure 5: A picture that visualizes a MOST Control Frame.

• 8 bytes are used for administrational purposes. • 2 bytes are used for transporting the source address. • 2 bytes are used for transporting the target address. • 1 byte is used to identify the message type; i.e. “system” or “normal” messages. • 17 bytes used for the MOST control message’s payload. • 2 bytes are used for CRC Checksum Data

All transportation of data i.e. commands and status reports between Function Blocks are contained within the 17 bytes of payload. The Technology of how to send and receive frames on a low level will be omitted since this is out of the scope for the thesis.

2.5 Control Messages There are two kinds of control messages, they are called: Normal and System messages. Normal messages provide the foundation for communication between functional units in a MOST network. In general, all Network Administration related communication uses this channel. System messages on the other hand provide administration and debugging on a chip level. Before describing how to send and receive messages there are some terminologies that need to be explained, they are: Function Block, Instance, Function, Operation Type, Function Catalogue, Network Master and Central Register.

2.5.1 Function Block On the application level, a MOST Device contains multiple components which are called function blocks; e.g. tuner, amplifier, or CD player. There may exist multiple function blocks in a single MOST device, such as a tuner and an amplifier combined in a single device, which is connected to a MOST network via a common MOST Network Interface Controller [4]. There can be several components with the same function block in the same MOST network; e.g. in a MOST network there can exist four loud speakers.

8

Interfacing MOST networks from Pantera A Function Block has an identifier called Function Block Id. If there exist two exactly alike function blocks in a MOST network they will have the same Function Block Id. Addressing one of them would therefore be a problem unless separated by the Instance Id (explained in the following chapter). There are three types of function blocks. The first type is called: “a slave” and it is a function block that always is controlled by another function block. The second type is the Human Machine Interface (HMI), a function block with an interface to the user. The last type is the controller, using functions within other function blocks.

2.5.2 Instance There might be several exactly alike function blocks with the same Function Block Id in a MOST network. In order to address one of several function blocks with the same function block id unambiguously an identification number is needed. Therefore every function block has an Instance Id. If there exist two or more exactly alike function blocks on a network then the first detected function block will have its instance id set to 1, the second will then have its id set to 2 and so forth. However there is also possible to set the instance id manually.

2.5.3 Function A function is an operation that a certain function block can perform. Each function block contains a number of functions. For example a CD player possesses functions such as: Play, Stop, Eject, and Play. A function has a unique Function Id for a specific function block. A function can be classified as: methods, properties and events. A method is a function that can be started and then produces a result after a definable period of time. An example would be the start-up of the tuners auto-scanning. Properties can be read or written; a property is normal represented by a variable that represents something such as limit or a status. An example is shows in figure 6, were the HMI sends the instruction “Heating.Temp.Get” to the function block “Heating”, which in turn replies by sending the status message “Heating.Temp.Status(27)”

Figure 6: Get a property.

9

Interfacing MOST networks from Pantera Properties of a function block may change without an external influence; e.g. the temperature in the car or the current time of a CD player. To display current values, a cyclic reading of the properties could have been done, i.e. polling. To reduce the communication between function blocks, they only send status reports when the value changes. These status reports are called events.

2.5.4 Operation Type The Operation Type Id specifies the operation applied to a property or a method [2]. Depending whether the applied function is a property or a method there are different columns for what the operation type id performs. Commands are Operation types used by a Controller to access Functions. Reports are transmitted by Functions as a reaction to the specific commands; e.g. to report a status as a result of a process or an error (see figure 7).

Figure 7: . Operation Types for properties and methods.

10


2.5.5 Addressing There exist two different ways of addressing: functional- and physical-addressing (figure 8). The functional address exists on an application level and is based on the Function Block Id and Instance Id meanwhile the physical address is based on the targets node address.

Figure 8: Functional and Physical addressing

The Logical Node address is calculated by adding an offset value of ‘0x0100’ to the Node Position, starting with the device containing the Timing Master as the one with the lowest Node Position; i.e. ‘0x0000’. Let’s for example suppose that the Timing Master in figure 9 has been assigned the Logical Node address ‘0x0100’, then the first node on the ring will be assigned 0x0101 as its Logical Node address, and the next one ‘0x0102’, and so on.

Figure 9: Node Position address.

11


2.5.6 Network Master There must be exactly one Network Master in a MOST network [4]. It contains the Timing Master used for controlling the System State and administration of the Central Register. In other words it monitors the network for certain events and continuously managing incoming information from the Slaves on the network about their current function block configuration as well as informing the Slaves about changes done in the central registry.

2.5.7 Central Register The Central Register is generated by the Network Master during the initialization of the network which continues to administrate it until the Network Shutdowns. It is an image of the physical and logical system configuration, containing the logical node address and the respective function blocks for each device; a device is identified by the unique combination of a function block id and instance id (see figure 10).

Figure 10: Central Register

2.5.8 Function Catalogue The Function Catalogue is a kind of library that contains information of Function Blocks, Functions and Operations present in a MOST network. The Function Catalogue is needed when translating control messages from hexadecimal to text and the other way around. It also gives the user an overview of what kind of operations a network supports. The catalogue has to be present for each MOST network in order to translate control messages back and forth. The structure of the catalogue is standardized and maintained by the MOST workgroup Device Architecture (WG_DA) and has to be created manually and stored in a XML file. For each Function Block a description of its Functions, Operation Types, Parameters, return values and possible errors are present in the XML file. An example of a template for a XML file containing a function catalogue is given in figure 11.

12


Figure 11: An XML file

13


3 Evaluation From the feasibility of MOST networks, we continued with analyzing the existing tools: Optolyzer and Pantera as well as interviewing their users. Unfortunately we discovered that Optolyzer was a bottle-neck, something that limited the time needed for its evaluation it; preventing us from examines it as much as we wanted. Question to be answered were. How were the tools used today? Which functionality was used, required or desirable? Which was our user-group? Which constraints existed?

3.1 Optolyzer and Optolyzer4MOST

3.1.1 Overview The Optolyzer tool consists of two parts: the software Optolyzer4MOST (see figure 12) and the hardware Optolyzer. This is the existing tool used on the market today for conducting analysis and simulations on MOST networks and is developed by the Oasis; a German company. Optolyzer is able to operate in two basic modes: spy and node mode [5]. In Spy Mode, the Optolyzer tool (further on referred as the Optolyzer) acts like a network analyzer for control messages. All traffic on the network is supervised by the Optolyzer, even messages and data that aren’t addressed to it. It may therefore be used as a logger for all data communication that occurs on the MOST network, which is of great importance when trying to localize an error. By connecting an Optolyzer and a portable PC to a car, it can act like a “real life”-logger; yielding valuable analysis of the behaviour by the car in its real environment. In Node Mode, the Optolyzer acts like a real device in the network. It has the ability to simulate a virtual device communicating with other virtual devices in a virtual network. In addition, it is possible to connect virtual devices to a real hardware in a real network. Three different blocks exists: the control block, bus analyzer and the MOST Simulation Interface (see figure 12).

Figure 12: The Main Window in the Optolyzer4MOST application

14

Interfacing MOST networks from Pantera The first block is the Control Block. It is responsible for administration of global settings, setting properties and sending of control messages. The second is the Bus Analyzer which collects bus events like control messages, lock, unlock light and error conditions; all of them assembled in a central message buffer with a timestamp. Lock and unlock light refer to turning on and off the light in the POF cable. The last block is the MOST simulation interface. It covers all development steps in the system and is responsible for simulation of virtual devices communicating with each other, virtual devices in a virtual network, virtual devices communicating with real devices in a real network and the sending and receiving of messages as well as the handling of group and logical addresses (see figure 13).

Figure 13: An outline of a network with virtual nodes connected to real hardware,

controlled by “Opto4Most_1” (Master), “OptoMost_2” (Slave) and “VInterface” (virtual network).

3.2 Pantera

3.2.1 Overview Pantera is an analysis, prototyping and test automation tool for embedded intelligent electronics [6] (see figure 14). It runs on any computer under Windows and can interface physical electrical signals of the test object by supporting data acquisition (DAQ) as well as networking cards from different manufacturers. Pantera can operate in three different modes: design, execution and analysis mode. These modes are used for “designing sets of test programs”, “supervise and control test execution” and “analyze the results”. Pantera is a signal-based system that executes real-time programs encapsulated in components communicating via ports and connected by signals. These signals are event-driven; i.e. they can react to events on their in-ports as well as generate events on theirs out-ports.

15


Figure 14: Project Window in Pantera with two CAN ports

All messages are sent or received trough one of the following techniques or a combination of them: signals, E script or E packets. The creation of signals is specific for each network type, but the use of E script and E packets are the same. An E packet is a collection of subroutines developed for a specific network type. These packets may then be used from the E-Script by the user when he creates the test. A signal is defined as any piece of information that the system can interface; e.g. a CAN frame, an analogue electrical voltage or a software model variable. All signals have a data type which determines the kind of values that are valid for the signal. After the signals have been created they appear in the Signal View (see figure 15).

Figure 15: Created CAN signals

16

Interfacing MOST networks from Pantera Different components use signals for different purposes. There exist several types of components (see figure 16), e.g. loggers, generators, and test controllers. Each controller is specialized for a specific task: A logger reads signals, a generator writes them and a test controller controls the execution of the test itself.

Figure 16: The layout at the “test level”

Many components are pre-defined and delivered with the program itself. As an extent to this, it is possible to create user defined components by using the built-in E-language (see figure 17) from an E-Script. A user defined components behavior is controlled by using one of two available execution semantics; state charts and sequential programs. An E state chart is a powerful hierarchical state machine; supporting parallel executing states, meanwhile a sequential E program is an ‘ordinary’ (imperative) program that executes statements sequentially from the top to the bottom.

Figure 17: An example of an E-Script using a CAN signal

17


3.3 Interviews As a part of the evaluation, we chose to interview users whom had worked with Pantera and Optolyzer, to get a better understanding of how the tools were used today and which functionality they required and asked for. The results are summarized as:

1. It must be possible to send, read, log and view control messages. 2. It must be possible to send and read control messages through signals and E-Scripts. 3. It must be possible to get a timestamp for a received control message. 4. It must be possible to configure devices, ports as well as creating test cases using

signals or E-Script, even when not connected to the network. 5. It is desirable to add and configure more than one PumaMOST device for a network. 6. It is desirable to convert the received control messages between different data

formats; e.g. text, hexadecimal, decimal and binary. 7. It is desirable to send repetitive control messages. 8. It is desirable to implement a pause of the log; i.e. the addition of new control

messages on the screen should be stopped, but the actual logging would continue in the background for later usage when resuming the log.

9. It is desirable to be able to filter signals, e.g. view only signals from certain devices on the network or a special type of messages; such as sent, received or error.

10. It is desirable to echo a sent control message; i.e. log it with a timestamp generated when it was sent on the network.

11. It is desirable with a spy mode; i.e. the possibility to read all messages sent on the network, even if not addressed to the PumaMOST device itself.

12. It is desirable to view information about the devices on the network, their status and offered functionality.

3.4 Discussion Optolyzer offers a great set of tools for testing, supervising and controlling a MOST network, but it does not support automated tests as in the case with Pantera. Our group of interest wants to run automated tests of the functionality (embedded software) developed for devices on a network in order to save time and money. From the evaluation we became aware about a few constraints summarized as:

• Only the control channel is used when communicating with MOST devices in order to test their functionality which excluded the other two channels used for streamed data.

• Pantera is a tool that will support software developers in testing (automated tests) and debugging of embedded software, implemented in the MOST devices that are connected to the network.

• We were dependent of the PumaMOST device when connecting to a MOST network. (this required that the new PumaMOST driver would be delivered in time)

• We were constrained to integrate our solution in the existing Pantera framework; i.e. we were forced to following the existing software architecture as well as using C++.

• We were limited to twenty weeks of full-time work. 18

Interfacing MOST networks from Pantera After finishing our evaluation, we decided which functions to implement of those items (1-12) listed in chapter 3.3, and in which iteration. There were no doubts whether we should chose number one to four, since they were required by the users. However, the remaining numberings were only expressed as desirable, yielding a further examination. It is worth mention that we first came to the conclusion of only using functional addressing; a much easier way to address a device compared to the use of physical addressing. This approach was however overthrown when we realized that the PumaMOST device lacked support for functional addressing, forcing us to support physical addressing. Before a user can send or receive a control message, a device must be added to the project, followed by a configuration of the device and its physical port. As a result of these configurations, signals will be created, and then, at some point of time, exported by the user to higher ‘layers’ or ‘views’ (see figure 18), all the way up to the Test ‘layer’, before they can be used in automated tests.

Figure 18: Layers or ‘views’

A question raised during the evaluation was: which kind of configuration was needed and where were to put it? A closer look at how things were solved for other type of devices, e.g. the CAN device, gave us some guidelines. An investigation showed us that there ought to be two GUIs; one for configuration of the device and another for the ‘physical port’ (logical). We decided to put the configuration of the device in the “device configuration GUI”; i.e. configuration of its bus port (hardware): USB, COM or WLAN. The setting of the PumaMOSTs configurable parameters and the signal creation were however put in the “physical port configuration GUI”. A decision based on how other devices were managed; giving Pantera a uniform look and feel.

19

Interfacing MOST networks from Pantera Still there were some questions to be answered. Which configurable parameters needed to be set for the PumaMOST device? Which signals were to be built and which data type should they have? From our study of MOST networks we learned that the device must be able to switch between ‘Master’ and ‘Slave’. Master had to be chosen when it should act as a “Network Master” and as a slave when a network master already existed on the network. Another request from the users was to be able to use the device in ‘Spy’ mode, a very useful feature for testers, but for now it was rejected due to lack of support in the actual device itself. Yet another request was the possibility to ‘echo’ messages with a timestamp, showing the time when they were sent on the network. This feature helps the tester to estimate the time elapsed for the execution of a requested operation, which may be a useful thing to know when analyzing the performance of the verified functionality. We also chose to add support for the toggling between frequencies, due to the fact that the network supported communication using two different frequency rates. The support for sending, receiving and viewing messages sent on the network is a feature that must exist in order to verify the developed functionality embedded in the MOST devices. However, the question of how to send and view the messages was therefore something that we needed to investigate a little bit further. From Optolyzer there exist a possibility to verify the functionality in a MOST device by creating control messages, either manually or by selecting from a hierarchically tree view (see figure 19).

Figure 19: Building and sending a control message in Optolyzer.

The use of a graphical tree hierarchy is built upon a loaded function catalogue; this hides the need of knowing how the network is configured. It is much easier to browse for the desired functionality than examining the network for addresses, function blocks and functions available for the devices. In Pantera we were constrained to using signals when communicating with MOST networks, forcing us to decide which signals to be used and how to construct them. We came to a conclusion were we needed three different types of signals.

20


• One type of signal when sending control messages on the network • One type of signal when receiving control messages from the network. • One type of signal when receiving acknowledged messages from the PumaMOST.

Our suggestion was that for each type of signal the user should be able to construct a general signal that always should exist. As an extension to this we thought that it should be possible to create several user specific signals; each one unique and assigned a specific operation for a function in a function block.

• Three base signals must exist; one for each type. • Several user signals may be created dynamically based on the operations to be

executed. They would be constructed upon the selection from a loaded function catalogue as in the case with Optolyzer. This would have the benefit to hide the fields: source address, target address, function block id, function id and operation type from the user when certain operations needed to be accessed. The only things remaining for the user to fill in would be the instance id and parameters for the operation itself.

A feature that would ease the fill-in of the required fields for a signal would be to generate them from an imported function catalogue; a generated parameter string could then be copied and pasted into an E-script. This was a feature we would have wanted ourselves and therefore it seemed like a good idea to choose it. A very important part of the solution is the logger. Without a logger it is impossible to view the result; seeing what has been sent and received on the network. In Optolyzer, messages are supervised by viewing them in the log; both the transmitted and received messages (see figure 20). The logging is divided into several fields which ease the readability; e.g. source address, target address, priority, timestamp, Function Block ID, Instance ID, Operation Type, Length of Message and Data.

Figure 20: A log for control messages in Optolyzer

Messages received could be shown or hidden by setting up different filters, e.g. signals from certain devices on the network or a special type of messages (sent, received or error). It is also possible to convert messages between different data formats: hexadecimal, decimal, octal, binary, dword, word and byte values.

21

Interfacing MOST networks from Pantera In Pantera messages are logged in the same way for all type of networks (see figure 21). The information shown is: the test name, start time, signal name, values and timestamp. Compared to the Optolyzers log is Panteras log much less detailed, a real drawback.

Figure 21: The signal log in Pantera

In addition to using this log and in harmony with the users’ requests, we suggested an adding of a MOST specific log. Messages sent and received would then be interpreted in a more legible way seen from a user perspective. The Source Address, Target Address, Function Block, Function and Operation Type were suggested to be viewed as either text or hexadecimal values. All other values were decided to be shown as hexadecimal values. In order to help the users to see the current network configuration we decided to provide an feature that listed the devices connected to it, functions offered and which device they belonged to, as well as other information of interests Another interesting feature in Optolyzer is the possibility to build virtual MOST devices on a virtual network, as well as operate on them as they were real devices connected to the real network. It makes it possible to define and run tests without having any hardware equipment; which may be a bottle-neck, as it is in our case. However, even if this seemed like a good idea, we realized that it would take too much time to be considered realistic, therefore it was abandoned. Optolyzer can be used to simulate common network errors such as: “Receive buffer full Simulation”, “Lock Loss/Error Simulation” and “Bus load generator”. Activating the “Receive buffer full Simulation” disables the automatic draining and realising of the receive buffer on a MOST device. As a result of this, any message sent to it will be rejected. The “Lock Loss/Error Simulation” generates sequences of Lock Loss, or Light Off Errors. The “Bus load generator” allows generating a specific Bus Load by sending automatically generated messages. One drawback is that during bus load stress, all analyzing functions are suspended. After considering this feature, it was overthrown, because off no value added functionality to our user group. They are not supposed to test the network itself, only verifying the embedded software in the devices on the network. Optolyzer offers control of a device’s functionality in a very attractive way for testing of its functionality, which may be to complex for being handled via the sending of a single control message. A user can build a graphic remote control (see figure 22). These controls are built by generating buttons and assigning control messages to them. 22


Figure 22: A graphic remote control. Once again we had to reject a very useful feature due to lack of time. But this is absolutely something to take a closer look at in a later version of Pantera. We also thought that it would have been nice to have a tool for creating and editing of XML files, containing function catalogues. However this feature was rejected due to the discovering of a free tool, doing exactly this. Our suggested functionality can therefore be summarized as:

• Support for configuration of the PumaMOST device. • Support for sending, receiving and viewing of MOST control messages (Control messages are sent and received as signals) • Support for creating of MOST signals, base signals and user signals; the later are to be

created graphically from a loaded function catalogue. Signals which are to be used within an E-Script upon the creation of an automated test.

• Support for logging of MOST control messages in a MOST specific signal log for improved readability.

• Support for filtering of MOST control messages. • Support for echoing of MOST control messages. • Support for generating a parameter strings from a function catalogue which may be

copied and pasted into an E-Script to avoid a manual entering of the necessary fields asked for when using a base signal.

• Support for listing of MOST devices connected to the network, showing function blocks, functions and operations as well as the device to which they belong, together with other interesting information.

In addition, our supervisor at Movimento asked for a MOST specific E-Packet to be created.

23


4 Requirements

4.1 Functional Use cases were formulated from the suggested functionality to find out how the users would interact with the system. A Use Case Diagram with use cases, actors and their relations is shown in figure 23 below. The actor to the left is the primary actor, the one who uses the system directly and the actors to the right are the supporting actors; supporting the system in its tasks.

Figure 23: A use case diagram for the Pantera application.

A dependency is symbolized by a doted arrow.

24

Interfacing MOST networks from Pantera After the use cases were constructed (see appendix A), a sketching of the GUI prototypes was made (see Appendix B), followed by the requirement specification and thereafter a system test specification (see Appendix C). The requirements (R1 – R7) are listed below.

R.1 R.1.1 R.1.2 R.1.3 R.1.4 R.1.5 R.1.6

Add a device. The user should be able to add a PumaMOST device, even if not connected to a PumaMOST. The GUI should start up with a default configuration. The GUI should support the selection of any of the available port types; i.e. USB, COM or WLAN. The user should be able to use an USB port when communicating with a MOST network. The user should be able to cancel any selections made. The user should get an error message when an error occurs.

R.2 R.2.1 R.2.2 R.2.3 R.2.4 R.2.5 R.2.6

Edit a device. The user should be able to edit a PumaMOST device, even if not connected to a PumaMOST. The GUI should start up with the existing configuration. The GUI should support the selection of any of the available port types; i.e. USB, COM or WLAN. The user should be able to use an USB port when communication with MOST networks The user should be able to cancel any the selections made. The user should get an error message when errors occur.

R3 R.3.1 R.3.2 R.3.3 R.3.4

Configure a Port The user should be able to configure a physical port for a PumaMOST device, even if not connected to a PumaMOST. The GUI should start up with a default or an existing configuration, if available The GUI should support the selection of setting the working frequency to 44.1 kHz or 48 kHz, for a PumaMOST device. The GUI should support the selection of setting the working mode to MASTER or a SLAVE for a PumaMOST device.

25


R.3.5 R.3.6 R.3.7 R.3.8 R.3.9 R.3.10 R.3.11 R.3.12 R.3.13 R.3.14 R.3.15

The GUI should support the selection of setting the echo mode to ON or OFF for a PumaMOST device. The user should be able to use the PumaMOST as a MASTER or a SLAVE The user should be able to use the PumaMOST in echo mode ON or OFF. The user should be able to view a loaded and parsed function catalogue in a tree hierarchy. The user should be able to create base signals used for MOST control messages. The user should be able to create user signals used for MOST control messages. The user signals are not mandatory and should be built from the imported function catalogue. The user should be constrained to use signal names starting with one of the character [a-z][A-Z], followed by none or any combination of the following characters [a-z][A-Z][0-9][_] [.]. Moreover a name equal to “Unamed” is not allowed. The user should be prevented from using an already existing signal name. The user should be able to edit the configuration The user should be able to cancel any changes made The user should be notified about errors that may occur.

R4 R.4.1 R.4.2 R.4.3 R.4.4 R.4.5 R.4.6 R.4.7

Run a Test The user should be able to send and receive MOST control messages from within an E-Script by using MOST specific signals The user should be able to send and receive MOST control messages from within an E-Script by using MOST specific E-Packet(s) An E-Packet for MOST should be constructed to be used from within an E-Script. The System should be able to send and receive MOST control messages based on physical addressing when a test has been started and no errors have been reported. The System should log the execution of the test in the System Log in order to make it possible for the user to be notified about events and errors that occur. The System should echo a sent MOST control messages when echo mode is on. The System should log MOST control messages in the Signal Log to be viewed by the user during run-time.

26


R.4.8 R.4.9 R.4.10 R.4.11

The System should log MOST control messages in the Execution Results to be viewed by the user after the test has been stopped or aborted. The user should be able to stop the test. The user should be able to abort the test The System should abort the execution of the test whenever - The System fails to connect to the PumaMOST device. - The System fails to configure the PumaMOST device.

R.5 R.5.1 R.5.2 R.5.3 R.5.4 R.5.5

View a Function Catalogue The user should be able to load a function catalogue by opening its existing XML file. The user should get an error message whenever a load of a function catalogue fails. The user should be able to view the function blocks, functions, operations and parameters contained in a valid function catalogue as a tree hierarchy by their textual names, in order to show their numerical values in a hexadecimal format upon selection. The user should be able to fill in the source address, target address and instance id. The user should be able to copy the parameter values generated from the selection.

R.6 R.6.1

View the MOST Signal Log The user should be able to view the Execution Results in a more readily format where the message has been separated in the columns: 1: Number 2: Timestamp 3: Echo Flag 4: Source Address 5: Target Address 6: Function Block Id 7: Instance 8: Function 9: Operation Type 10: Data The columns 1-2 is shown as decimal values, columns 3-9 as hexadecimal or string values depending of the users choice and column 10 as hexadecimal values. The columns 3-9 should be translated to strings from hexadecimal values by mapping them to a function catalogue.

27

Interfacing MOST networks from Pantera R.7 R.7.1 R.7.2 R.7.3

View the Network Peripherals The user should be able to view current functionality offered by the devices on the MOST network. The user should be able to view the addresses for the devices currently attached to the MOST network. The user should be able to view information (if present) of a manufacturer of a device.

28

Interfacing MOST networks from Pantera From the listed requirements above, a weighted classification of the importance of each function requirement was made. These were divided into three levels: High Importance (H), Medium Importance (M) and Low Importance (L). The functions could then be determined in which iteration (IT) they should be implemented (see table 1).

Table 1 Requirements classification REQ. H M L IT R.1.1 R.1.2 R.1.3 R.1.4 R.1.5 R.1.6

X X X X X X

1 1 1 1 1 1

R.2.1 R.2.2 R.2.3 R.2.4 R.2.5 R.2.6

X X X X X X

1 1 1 1 1 1

R.3.1 R.3.2 R.3.3 R.3.4 R.3.5 R.3.6 R.3.7 R.3.8 R.3.9 R.3.10 R.3.11 R.3.12 R.3.13 R.3.14 R.3.15

X X X X X X X X X X X X

X X X

1 1 1 1 1 1 1 1 1 2 1 1 1 1 1

R.4.1 R.4.2 R.4.3 R.4.4 R.4.5 R.4.6 R.4.7 R.4.8 R.4.9 R.4.10 R.4.11

X X X X X X X X

X X X

1 2 2 1 1 2 1 1 1 1 1

R.5.1 R.5.2 R.5.3 R.5.4 R.5.5

X X X X X

2 2 2 2 2

R.6.1 X 2 R.7.1 R.7.2 R.7.3

X X X

2 2 2

29


4.2 E-Packet E-Packets are to be used from within an E-Script in order to make it easier to access frequently used operations on the MOST network since there are fewer parameters to fill-in by the user. All parameters must be entered as hexadecimal values, they are to be found in the function catalogue, defined for a MOST network

4.2.1 sendMessage Table 2: Return values and parameters. The function is defined as follows:

return1 sendMessage(param1, param2, param3, param4, param5)

Identifier Type Name Description return1 bool - Returns true if successful, otherwise false param1 unsigned short& fblock The function block id param2 unsigned short& Instance The instance id param3 unsigned short& function The function id param4 unsigned short& optype The operation type param5 buffer& data At calls: The parameters

At return: The return values This Function is used for sending a MOST control message to a specific MOST device; i.e. a unique combination of the “function block id” and “instance id”. The device is found by mapping the combination “function block id” and “instance id” to an address found in the “Central Register”.

4.2.2 sendMessageToGrp Table 3: Return values and parameters. The function is defined as follows:

return1 sendMessageToGrp(param1, param2, param3, param4)

Identifier Type Name Description return1 bool - Returns true if successful, otherwise false param1 unsigned short& fblock The function block id Param2 unsigned short& function The function id Param3 unsigned short& optype The operation type Param4 buffer& data At calls: The parameters

At return: The return values This Function is used for sending a MOST control message to a MOST device of the same type but with different instance id, e.g. to all speakers in the car.

30


4.2.3 sendMessageToAll Table 4: Return values and parameters. The function is defined as follows:

return1 sendMessageToAll(param1, param2, param3)

Identifier Type Name Description return1 bool - Returns true if successful, otherwise false Param1 unsigned short& function The function id Param2 unsigned short& optype The operation type Param3 buffer& data At calls: The parameters

At return: The return values This Function is used for sending a MOST control message to all MOST devices; i.e. a broadcast message.

4.2.4 setProperty Table 5: Return values and parameters. The function is defined as follows:

return1 setProperty(param1, param2, param3, param4)

Identifier Type Name Description Return1 bool - Returns true if successful, otherwise false Param1 unsigned short& fblock The function block id Param2 unsigned short& Instance The instance id Param3 unsigned short& function The function id Param4 buffer& data At calls: The parameters

At return: The return values This Function is used for setting one or more properties for a MOST device, e.g. the temperature for the automatic climate control in the car.

4.2.5 getProperty Table 6: Return values and parameters. The function is defined as follows:

return1 getProperty (param1, param2, param3, param4)

Identifier Type Name Description Return1 bool - Returns true if successful, otherwise false Param1 unsigned short& fblock The function block id Param2 unsigned short& Instance The instance id Param3 unsigned short& function The function id Param4 buffer& data At calls: The parameters

At return: The return values This Function is used for getting one or more properties for a MOST device, e.g. the temperature in the car, given by the automatic climate control. 31


5 PumaMOST The PumaMOST is an electronic diagnostic and analytical tool for vehicle systems and functions [7] (see figure 24). This piece of hardware isn’t much bigger than a cellular phone. It is mainly used to perform diagnostic tests on vehicles to make sure that the electronics in them works as it should. It is also used to download software to the devices on the network as well as in product development contexts for verification or control of functions in those peripherals attached to the network. The PumaMOST consists of both hardware and updatable software. It has several diodes placed of its front cover, which is used for communicating with the technician, in order to help him making a proper diagnose.

Figure 24: The PumaMOST device

6 Analysis The system environment consists of the Pantera application (software) and the PumaMOST (hardware). The application consists of two parts: a client (GUI) and a server. They can be located on the local PC or divided between two different computers. The connection between the software and hardware is made through the Universal serial Bus (USB) port by using the RP1210 interface (see figure 25).

Figure 25: System Environment

32


6.1 Concepts A conceptual model of the system is shown in figure 26 and was produced to get a better understanding of the concepts and how they were related to each other.

Figure 26: Conceptual Model of the system

33

Interfacing MOST networks from Pantera The purpose of implementing support for MOST networks in Pantera is to make it possible to use it as a test automation tool for verifying of the functionality in MOST devices; i.e. embedded software. Prior to the Design- and the later Implementation-phase, it is important to know the concepts and the relations between them. If not explained properly, it would have been really hard to do a well structured design of the system. The concepts are going to be explained in the remaining part of this sub chapter. Let’s start with the case of adding a device. The ‘device’ we are talking about is the PumaMOST device. It works as a ‘link’ between Pantera and a MOST network making it possible for them to communicate. A PumaMOST or a MOST device can only be connected to one network at a time. The network however may consist of up to 64 devices. When a user wants to add a device, it is done from the “Device GUI” shown in the conceptual model. This GUI is in turn related to the “Device Configuration GUI” from where the user may select the “Port Type”, to be used as the port (hardware) through which communication occurs. A “Port Type” is with other words the port on the backside of an ordinary PC, e.g. a COM or USB port, but it can also be a WLAN card. It should be possible to configure several ‘devices’ for a single network or several different networks. Each ‘device’ must have a unique combination of port type and port number. The port number is only a logical number used in Pantera and has nothing to do with the hardware’s physical port. After the device has been added, its physical port has to be configured from the “Port Configuration GUI”, where configuration of parameters for the PumaMOST device are set and signals created. There exist two different kinds of signals; “base signals” and “user signals”. Base signals can be used for any type of MOST control message. User signals on the other hand, are created for a specific operation, e.g. set the temperature in the Automatic Climate Control (ACC) device. User signals are created by loading the function catalogue for a MOST network from where it is possible to graphically select the available operations, by clicking in the tree view. The signals can be used from within an “E-Script”. In order to ease the filling in of their parameters (especially for the base signals), it is possible to build the parameter string from the “Function Catalogue GUI” by choosing the desired operation and then copying the generated parameters directly to the E-Script. From the E-Script it is also possible to use “E-Packets”, which are sets of predefined E-Scripts. In order to communicate with the Most Devices on the MOST network via the RP1210 interface and the PumaMOST device there must exist a “Test” to which the E-Script is connected to. A test that is run will produce a “System Log” and a “Signal Log” The System Log will print the test events that occur and the Signal Log the traffic generated on the MOST network. The Signal Log consists both of a graphical logger and a text based logger; where the later consist of an existing general log and a new MOST specific log. The new text based logger will ease the interpretation of the MOST control messages that arrives.

34


7 Interfaces

7.1 RP1210 To be able make a connection to a MOST network from a PC, there must exist a communication via the PumaMOST device. It is done by using an interface named RP1210, developed as a standard by the Technology and Maintenance Council (TMC) of the American trucking Association. This API provides connections to a vehicle network through any application under Windows 2000 or Windows XP. The API eliminates the need for developers to understand or write device drivers, and allows them to focus totally on writing the application layer [8].

7.1.1 RP1210_ClientConnect __declspec (dll export) WINAPI RP1210_ClientConnect (

HWND hwndClient, short nDeviceID, char far* fpchProtocol, long lTxBufferSize, long lRcvBufferSize, short nIsAppPacketizingIncomingMsgs

);

7.1.2 RP1210_SendCommand __declspec (dll export) WINAPI RP1210_SendCommand ( short nCommandNumber, short nClientID, char far* fpchClientCommand, short nMessageSize );

7.1.3 RP1210_SendMessage __declspec (dll export) WINAPI RP1210_SendMessage ( short nClientID, char far* fpchClientMessage, short nMessageSize, short nNotifyStatusOnTx, short nBlockOnSend, )

7.1.4 RP1210_ReadMessage declspec (dll export) WINAPI RP1210_ReadMessage ( short nClientID, char far* fpchAPIMessage, short nBufferSize, short nBlockOnRead )

35


7.1.5 RP1210_ReadMessage __declspec (dll export) WINAPI RP1210_GetErrorMsg (

short ErrorCode, char far* fpchDescription

);

7.1.6 RP1210_ReadMessage __declspec (dll export) WINAPI RP1210_ClientDisconnect (

short nClientID );

7.1.7 RP1210_ClientDisconnect __declspec (dll export) WINAPI RP1210_ClientDisconnect (

short nClientID );

7.2 PumaMOST The analysis conducted of the PumaMOST’s interface implied that there is a demand of upgrading its interface to support the sending and receiving of MOST control messages (inclusive error messages). Furthermore support for set and get the receive filter in the PumaMOST device is also needed. Therefore, frames had to be specified, containing the messages sent between the PC and the PumaMOST, via the RP1210 protocol. Three different frames were designed. In order to distinguish different kinds of messages from each other we had to add an identifier for our MOST specific control message. This was in harmony with an already existing solution where messages were identified by the value in the “command field”. For these messages, the value “0x000B” was chosen. A “length” field was added to specify how many bytes that followed. An “operation” field was added to specify the kind of operation to be executed; i.e. if it should be forwarded and sent on the MOST network or if a configurable parameter in the PumaMOST device should be set or fetched.

7.2.1 MOST Filter Message Frame To reduce the number of messages forwarded from the PumaMOST to the PC, to only those of interests, there existed a need of setting a ‘message receive filter’. The “CH” field sets the channel to be forwarded, e.g. the control channel, meanwhile the remaining fields’ sets up the filter for function blocks, functions and so on (see figure 27 and table 7). This frame is thus used for setting and getting the filter configuration for MOST messages that arrive from the network.

Command Length Operation CH FM1 FM2 FM3 FM4

Figure 27: MOST Filter Message Frame; both “Set” and “Status”

36


7.2.2 MOST Control Message Frame This frame is used for sending MOST control messages between the PC and PumaMOST device (see figure 28). The priority field makes it possible for a message with a higher priority to pass by a previously sent message with a lower priority that exists in the send queue. The “Target” field refers to the node that shall receive the message and the “Source” field to the node that sends the messages. The “Data” field concerns the operation to be executed on the MOST devices targeted.

Command Length Operation Priority Target Source Data

Figure 28: MOST Control Message Frame

7.2.3 MOST Acknowledge Message Frame This frame is used for acknowledgment of a sent MOST control messages between the PC and PumaMOST device (see figure 29). The status fields reports the transmit status.

Command Length Status Priority Target Source Data

Figure 29: MOST Acknowledge Message Frame

7.2.4 MOST Error Message Frame This frame is used for forwarding MOST error messages generated on the MOST network (see figure 30). The “Error Type” field identifies the type of error and the “Error Message” field contains the actual error message.

Command Length Operation Error Type Error Message

Figure 30: MOST Error Message Frame

37


7.2.5 MOST Interface Description Besides designing the frames, there existed a need of defining the values to be put in the fields’ and their implication. A summary of values and fields which are used in the frames is shown in table 7. Table 7: Interface description for the frames shown in figures 27-30

Field Length

(byte) Description

Command 2 0x000B – MOST Encapsulated message Length 2 The length in bytes for the remaining part of the message Operation 1 0x00 – Rx Filter Set

0x01 – Rx Filter Status 0x02 – Send Control Channel Message 0x04 – Receive Control Channel Message 0xA2 – Acknowledge of previous sent Control Channel Message 0x0F – Error

CH 1 0x01 – Control Channel FM1 2 Filter mask for source Address FM2 1 Filter mask for Function Block Id FM3 1 Filter mask for Instance Id FM4 2 Filter mask for Function Id Error Type 1 Failed operation. Error Message 1 0x00 – General Error

0x01 – Incorrect Length 0x02 – Memory Allocation Error 0x03 – Tx Error 0x04 – Invalid Operation

Priority 1 A lower value gives higher priority (starts with value: 1) Status 2 0x0000 – No response

0x1010 – Transmission successful 0x1111 – Not supported 0x2020 – CRC error 0x2121 – Receive buffer full 0x3030 – CRC and transmission successful 0x3131 – Transmission successful and receive buffer full

Target 2 The Target Address For Tx Messages: (transmit) The address for MOST device(s) on the MOST networks. For Rx Messages: (received) The address for the PumaMOST device.

Source 2 The Source Address For Tx Messages: (transmit) The address for the PumaMOST device. For Rx Messages: (received) The address for MOST device(s) on the MOST networks.

38


8 Design Before the actual implementation phase, it is of great importance to have a clear idea about how to realize the implementation in order to build a well designed, user friendly and robust application.

8.1 Architecture The architecture consists of Pantera, a PumaMOST device and one or several MOST devices (see figure 31). The Pantera application is built from two different parts: a client and a server. The central part of the design is the sending and receiving of MOST control messages. The client uses an XML file containing a function catalogue in order to create user signals as well as building a data structure for rapid access to the data needed. The implementation of the PumaMOST driver was on commission to a consultant hired by Movimento. Pantera and PumaMOST communicate with each other via the RP1210 interface.

Figure 31: An overview of the physical architecture

8.2 Function Catalogue The encoding and decoding of control messages is of great importance in order to provide a user-friendly environment for the user. Therefore we decided to provide a way to easily encode and decode control messages based on a function catalogue (an XML file which is parsed and stored into an internal data structure upon load). The time spent decoding a control message has to be as small as possible, especially since it is used for encoding and decoding of MOST control messages during runtime. The maximum number of incoming messages to a node can be as much as 16 000 per second, which requires a fast access to the information needed. A very fast access method is to use maps. These provide direct access, i.e. O(1) to a node by using a key. The data structure of the Function Catalogue is built up as a tree. Figure 32 shows the four different kinds of maps used: “FBlockMap”, “FunctionMap”, “OpMap” and “ParameterMap”. The corresponding keys for the maps are the function block, id, the function id, the operation type and numerical order in which the parameter for the function appears in the parameter list.

39


Figure 32: Parsed information from the Function Catalogue loaded

from the xml-file is stored in four different types of maps.

There exists only one FBlockMap containing one or more nodes of the type “FBlockStruct”, which stores information about the function block as well as a reference to its child map. The information stored for a function block is its textual name, numeric id, kind of device (i.e. a tuner, speaker, etc) and a textual description of the device. For every node in the FBlockMap there exists a FunctionMap. A node in the FunctionMap (FunctionStrucst) stores information about the available functions for the actual function block node, as well as a reference to its child map. The information stored for a function is its textual name, numerical id, textual description and class reference (i.e. a property or method) For every node in the FunctionMap there exists an OpMap. The nodes in an OpMap (OpTypeStructs) stores information about the available operation types for the actual function node, as well as a reference to its child map. The information stored for an operation type is its textual name and numerical id. For every node in the OpMap there exists a ParameterMap. A node in the ParameterMap (ParameterStructs) stores information about the available parameters for the actual function node. The information stored for parameters is its textual name, textual description, data type and data type length

40


8.3 Signals There are two different kinds of signals used in Pantera: “Base Signals” and “User Signals”. The base signals, which are always present for a correctly configured device, handle all different kinds of MOST control messages in a MOST networks. The user signals are less general but easier to use from a user perspective since there would be fewer parameters to fill in. They are created separately from a function catalogue where each signal only handles a specific operation for a set of unique combination of function block id, function id and operation type.

8.3.1 Base Signals The Base Signals consists of three signals, used for different purposes, but with the same data type (see figure 33). The signals’ usage are specified by their suffixes; i.e. tx, tx_ack and rx. The first one is used for sending control messages (tx), the second for receiving acknowledged messages (tx_ack) and the last one for receiving messages (rx).

Figure 33:

The data type consists of seven different fields, all of them explained in table 8. All fields have to be filled in by the user before the message can be is sent on the MOST network. Table: 8

Field Description source The address for the device from where the message originates. target The address for the device to which the messages shall me sent. fblock_id The function block id on the targeting device inst_id The instance id that separates equal function block id: s from each other fkt_id The function id for the function to be executed. op_type The type of operation on the function to be executed. Data The parameters sent or returned.

41


8.3.2 User Signals The user signals ease the usage by minimizing the number of fields to be filled in by the user. A user signal is created graphically from a loaded function catalogue. Due to a limited time scope we chose to use the same data type for all user signals. A more suitable data structure would have contained the parameters to be set or return. As it is now, they have to be looked up in the function catalogue. The fields: fblock_id, fkt_id and op_type, defined for the base signals are set automatically upon creation of a signal, therefore they are not needed to be filled in by the user. The source and target fields are looked up in the central register and are set when running a test, before the message is sent. The resulting data type for the user signals can be seen in figure 34 and explained in table 9.

Figure 34:

Table: 9

Parameter Description inst_id The instance id that separates equal function block id: s from each other, to

make it possible to address a specific device when the target address are not filled in as a parameter by the user.

data The parameters sent or returned.

42


8.4 Client

8.4.1 Class diagram We were forced to following the existing structure used for other devices, such as the Puma CAN device, when designing the class diagram for the client side. The result is shown in the class diagram below (figure 35), where all classes outside the “mostdevgui.dll” are reused classes from the Pantera framework, meanwhile the rest is designed by us.

Figure 35: Class diagram for client side

43


8.4.2 Classes Table 10

Classes Responsibility MostBaseSignal Responsible for defining the data type for the MOST

base signals MostDevGui

The main entry point used by the Pantera framework when loading the DLL.

MostDevice

Responsible for the information common for all PumaMOST devices.

MostDeviceInstance Responsible for the information unique for an instance of a PumaMOST device

MostDeviceInstanceConfiguration

Responsible for saving and loading the device configuration data to and from a project file for a PumaMOST device

MostPhysicalPort

Responsible for the physical port of a PumaMOST devices

MostPhysicalPortConfiguration

Responsible for saving and loading the physical port configuration data to and from a project file for a PumaMOST device

MostSrvDeviceInstanceConfiguration

Responsible for holding the device information that needs to be passed from the client to the server when a test is run

MostSrvPhysicalPortConfiguration

Responsible for holding the physical port information that needs to be passed from the client to the server when a test is run

MostUserSignal Responsible for defining the data type for the MOST user signals as well as storing information about the related function block id, function id and operation type.

MostXMLData

Responsible for storing the data: function blocks, functions, operations and parameters, parsed by the MostXMLParser class.

MostXMLParser

Responsible for parsing a Function Catalogue from a XML file. The parsed data is stored in the MostXMLData class

TMostDeviceConfigurationGui

A GUI class which makes it possible for the user to select the port type and number for a PumaMOST device.

TMostFunctionCatalogGui

A GUI class which makes it possible for the user to view a parsed Function Catalogue graphically

TMostFunctionCatalogTreeGuiFrame

A GUI responsible for creating and manage the tree in which the Function Catalogue is displayed.

TMostPhysicalPortConfigurationGui

A GUI class which makes it possible for the user to configure a PumaMOST device and create signals

44


8.5 Server

8.5.1 Class diagram The result of the design of the server side is shown in the class diagram below (figure 36), where all classes outside the “mostdevs.dll” are reused classes meanwhile the rest is designed by us.

Figure 36: Class diagram for server side

45


8.5.2 Classes Table 11

Classes Responsibility MostBaseSignal Responsible for defining the data type for the MOST

base signals MostCentralRegister Responsible for management of the central register MostDevs

The main entry point used by the Pantera framework when loading the DLL.

MostSrvDevice

Responsible for the execution of a test; e.g. start stop, logging and error handling.

MostSrvDeviceInstanceConfiguration

Responsible for holding the device information that needs to be passed from the client to the server when a test is run

MostSrvPhysicalPortConfiguration

Responsible for holding the physical port information that needs to be passed from the client to the server when a test is run

MostUserSignal Responsible for defining the data type for the MOST user signals as well as storing information about the related function block id, function id and operation type.

PumaMostChannel Responsible for the actual communication between Pantera and the PumaMOST device via the RP1210 interface

PumaMostChannelRxThread Responsible for management of received MOST control messages

PumaMostChannelTx Responsible for management of sending MOST control messages

8.5.3 Run a test When a test is run, the server side of the Pantera application will try to open a channel to the PumaMOST device, i.e. make a connection (see figure 37). To avoid opening a channel more than once, a variable named “connected” was introduced, which implies that a new channel only will be opened if this variable is set to “false”. Whenever the channel is opened the configurable parameters in the device is set by sending messages to it. The configurable parameters to be set are: work mode, echo mode, frequency, ‘blocking time’ and the ‘receive filter setting’.

To make it possible to send messages originated from “user signals” which is based on functional addressing, there was a need for looking up the address, this since there must exist a source address to the device containing the operation to be executed. Normally this should be handled by the MOST device that acts as the master, but since the PumaMOST lacks support of managing a central register it must be built dynamically by the Pantera application whenever a test is run and user signals exist (how this is done will be explained in an upcoming chapter). 46

Interfacing MOST networks from Pantera The next step is to start a new “read”-thread that manages received messages meanwhile the “main”-thread will manage everything else. To make it possible to stop the “read”-thread from listening for messages we chose to introduce a variable named “runs”, which is set to “true” when the thread starts and set to “false” when stopped.

Figure 37: Run of a test

In order to protect a received message from being overwritten by another incoming message, some kind of protection must exist during the time it is processed. This was solved by introducing a “read” lock, reusing the existing OsEvent class (see figure 38).

Figure 38: The OsEvent class

47

Interfacing MOST networks from Pantera The OsEvent class hides the use of semaphores and has three interesting methods: clear(), wait() and set(). The private member “event” is set to “false” when calling the method “clear()” and to “true” when calling “set()”. By the call of “wait()”, two things can happen.

• If event equals “true”, it continues to the next source line • If event equals “false”, it waits until the event becomes “true”

When a test is stopped the channel will be closed; i.e. the channel is disconnected as soon as possible. This means that it will wait for the process to finish the sending or receiving of a message, resulting in a clean shut down. The solution was given by once again introducing locks. One “read”-event lock and a “write”-event lock. This solution forced the “main”-thread to wait for messages currently processed to be finished (see figure 39).

Figure 39: State Diagram for run of a test, showing the different states that may occur

on server side.

48


8.5.4 Send MOST Control Messages A message arrives as a signal with a data structure from an E-Script. The signal is then extracted and inserted in a frame, which is sent to the PumaMOST device (see figure 40).

Figure 40: Sending MOST Control Messages

In the case of a user signal, an extra step has to be performed before the signal is inserted in the frame. Extended signal information has to be fetched, containing the function block id, function id and operations type. Upon the creation of the signals, this information will already have been set on the client side making it possible to look up the target address for the designated MOST device in the central register (see figure 41).

49


Figure 41: Structure for retrieving information

needed when sending a control message based on a user signal

The central register consists of two different maps. One where the key is the Device Address meanwhile the values consists of the Function Block Id and Instance Id. The other map have a key which compounds of the Function Block Id and Instance Id meanwhile the value consists of the Device Address (see figure 42). By having two different maps we can map user signals in O(1), both when sending and receiving messages

Figure 42: The information needed in the

central registry When the PumaMOST device receives a MOST control message it divides it in two bytes segments, pack them in MOST frames, which in turn are put in the send queue, before they are sent on the network.

8.5.5 Read MOST Control Messages A PumaMOST receives a MOST control message from the network as MOST frames which are put in the receive queue. Since each frame only contains 2 bytes of those 32 used for a control message, they arrive as segmented messages. These have to be handled by the PumaMOST before the complete message can be checked against the receive filter and if passed, forwarded to the PC. At the same time, the Pantera application (server) listens for messages. The “read”- thread listen by using a technique called “blocking”. It will listen until a message arrives or a timeout occurs. Whenever a message arrives, the “command” and “operation” fields are read and checked to determine what to do with the message. If it is a MOST control message then it should be read from the frame and extracted to a temporary container. The “read”-thread will set the ‘read protection’, send a notification to the “main”-thread which will read it from the 50

Interfacing MOST networks from Pantera container, assigns it to the correct signal, which is sent to the log. Finally the read protection is released, making it possible to process the next incoming message (see figure 43).

Figure 43: Receiving MOST Control Messages

In this case there also exists an additional step for user signals compared to base signals. Whenever a message arrives originating from a message created from a user signal, it has to be looked up in different maps in order to map it to the correct user signal (see figure 44). By having a pointer to the Connection Port class, the data can be accessed in O(3) time. The maps will only contain Function Block Ids, Functions and operation types related to user signals. From the Connection Port we can get the related “Signal”, “SignalDef” and at last the desired signal name.

51


Figure 44: Management of a received control

messages that should be put in a user signal.

A problem that needed to be solved was whether the responses to operations sent to the same function block, instance and function was returned in the same order as it was sent. For example, consider the event that a message performing the operation “SetGet” is sent to the function ”Radio.1.frequency” and shortly thereafter a new message performing the operation “Get” on the same function block is sent. If the second message is received before the first one, there would be a problem with determining the signal from which the message originated. The result of this would be that we would not know to which signal it belonged. A detailed investigation showed that there was nothing to worry about since the messages are returned in the same order as they are sent.

52


9 Implementation

9.1 Environment We were forced to use C++Builder version 5.0, since Pantera is implemented in C++ and dependent of the Borland C++ specific GUI components.

9.1 Realization As mentioned earlier we were forced to follow the existing architecture in Pantera, which meant that the client and server parts were going to be realized as two Dynamic Link Library (DLL) files. A DLL is a file containing executable code and data bound to a program at load time or run time, rather than during linking. The transfer of configuration data from the client to the server was done by using an existing interface. Likewise, the information that had to be changed was saved in a project file by the reuse of existing classes. The source code and any detailed information of how our solution is implemented are omitted due to secrecy.

9.3 Results The classes and the Lines of Code (LOC) produced in our realization are shown in table 12.

Table 12: Classes LOCMostBaseSignal 98MostDev_pch 13MostDevGui 81MostDevice 278MostDeviceInstance 399MostDeviceInstanceConfiguration 323MostDevs 82MostPhysicalPort 685MostPhysicalPortConfiguration 349MostSrvDevice 638MostSrvDeviceInstanceConfiguration 429MostSrvPhysicalPortConfiguration 1077MostUserSignal 146MostXMLData 376MostXMLParser 588PumaMostChannel 711PumaMostChannelRxThread 610PumaMostChannelTx 267TMostDeviceConfigurationGui 253TMostFunctionCatalogGui 581TMostFunctionCatalogTreeGuiFrame 270TMostPhysicalPortConfigurationGui 913 9167

53

Interfacing MOST networks from Pantera In our solution we produced three different GUI:s, the actual outcome of the prototypes of these is shown in the following sub sections. The GUI prototypes can be seen in Appendix B.

9.3.1 MOST Device Configuration Dialog During the process of adding a MOST device (see Appendix D), this GUI (see figure 45) appears from which it is possible to choose the port type and number to communicate through (each MOST device must have a unique set of port type and number). The port type refers to the actual hardware meanwhile the port number is more like a logical channel.

Figure 45: MOST Device Configuration

54


9.3.2 MOST Port Configuration Form During the process of configure a MOST device and create the signals (see Appendix D), this GUI (see figure 46) appears, from which it is possible to make PumaMOST settings and creating signals. User signals are created by loading a function catalogue from a XML file and then selecting the desirable operations from the generated tree view.

Figure 46: MOST Physical Port Configuration

55


9.3.3 MOST Function Catalogue Form This GUI (see figure 47) appears when the user chooses to open it from the tools menu in Pantera. From here, hexadecimal values for a MOST message can be graphically created, based on a loaded function catalogue. Since the source address, target address and instance id are not a part of the catalogue, they must be entered manually.

Figure 47: MOST Function Catalogue

56


10 Test

10.1 Environment To test our solution we had a PumaMOST device (with the new driver installed), Optolyzer hardware, Optolyzer4MOST software and an information display (prototype) to be used in a modern car (see figure 48).

Figure 48: The test environment where the Optolyzer hardware is at the top, the display

to the left and the PumaMOST device at the bottom right.

10.2 Methodology We decided to conduct small units test continuously during the implementation to make sure that we did not end up with a big problem at the end, resulting in a lot of re-implantations. This was a choice made on decision not being familiar enough with the Pantera code. At the end we planned to have a final system test to verify the functionality defined by our requirement list.

57


10.3 Results The system test was never performed due to lack of time, caused by the very late delivery of the software used in the PumaMOST device; a software that we were highly dependent of. However we run a short test to verify that we could send and receive MOST Control messages. The tests result was nearby successful, except that the received message showed incorrect values cause of a minor bug in the software; the delivered messages source field ought to have a length two bytes, but had only a length of one byte, which resulted in an incorrectly decoded message.

11 Improvements First of all, there exists a need of completion of those planned features that was omitted due to lack of time. Then a thoroughly system test has to be done to assure a high quality of the implemented functionality. Secondly there are other features as mentioned in our evaluation that we think will make a difference when using Pantera together with MOST networks; these are encountered below. Verification of the devices functionality by the creation of control messages, either manually or by the constructing from a hierarchically tree view (graphically) as shown in figure 19. This would make it possible for a developer to rapidly test an operation with different parameter values, giving him an immediately feedback. Building virtual MOST devices on a virtual network and operate on them as they were real devices connected to the real network. This gives the possibility to define and run tests without having any hardware equipment; which may be a bottle-neck. Build controllers as in figure 22, this would offer a very attractive way of testing the devices functionality, which may be to complex for being handled via sending of single control messages. Using the PumaMOST device in something called “spy mode”, having it work as a real life logger. Set the address for the PumaMOST device making it possible to use more than one PumaMOST device on the network A graphical viewing of those devices and functions currently present on the MOST network.

58


12 Conclusions This thesis has been very interesting since it covered several for us new and interested fields. We have through our studies achieved a detailed understanding about the MOST technology. Learned about Optolyzer, Pantera, and the RP1210 interface. Defined our own interface, worked with embedded systems and improved our skills in using the C++ program language. During this interesting time we encounter some problems. The first was when we realized that the Optolyzer tool was a real bottle-neck, forcing us to use its manual as the primary source for our evaluation, and the real program as a second alternative. Another problem was the insufficient documentation for the PumaMOST device and its existing interface; a device under the state of development. Therefore we had to seek knowledge from those persons at Movimento that works with it. In fact we realized that a lot of things had insufficient documentation. This was one of the things that delayed and constrained us from realize all those things we had planned to implement from the beginning. However it may be worth mention that the scope of our suggested functionality is greater than the one specified in the project definition; saying that we only should evaluate the existing tools and making a test implementation for interfacing MOST networks from Pantera. A third problem was that the interface between Pantera and the PumaMOST had to be specified in a very early state, before our evaluation was finished, due to the long delivery time of the embedded software in the PumaMOST, containing the realization of the interface. Even though we made the specification on an early state we got a very late delivery caused by other commitments, which stand in our way, since they had a higher priority. This prevented us from doing a thoroughly system test. However since we succeed in sending and receiving a MOST control message between Pantera and a MOST device on the network we could conclude that we fulfilled the purpose; developing a test implementation which interfaced a MOST network from Pantera.

59


Glossary

A ACC Automatic Climate Control ACK Acknowledged API Application Program Interface, a set of routines, protocols, and tools for

building software applications A/V Audio/Video

B

C CAN Controller Area Network, a serial bus network of microcontrollers that

connect devices, sensors and actuators in a system or sub-system for real-time control applications

CD Compact Disc, a polycarbonate with one or more metal layers capable of storing digital information

COM The Serial Port at the Computer. CRC Cyclic Redundancy Check, a common technique for detecting data

transmission errors

D DAQ Data Acquisition, it is an analogue and digital card collecting data. DLL Dynamic Link Library

E EMI Electromagnetic Interference Ethernet A local-area network developed by Xerox Corporation in co-operation

with DEC and Intel in 1976

F

G GPS Global Position System, a worldwide global middle earth orbit satellite

navigational system formed by 24 satellites orbiting the earth and their corresponding receivers on the earth.

GUI Graphic User Interface

60


H HMI Human Machine Interfaces, a Function block in a MOST network that

has an interface to the user

I I/O Input/Output Interface A boundary across which two independent systems meet and act on or

communicate with each other. ISO International Organization for Standardization

J

K

L LOC Lines Of Code

M MOST. Media Oriented System Transport, i.e. the method of data transportation

in a MOST system, in particular the architecture and management of the bit stream.

Multimedia The use of computers to present text, graphics, video, animation and sound in an integrated way

N NAK Not Acknowledged

O OSI Open System Interconnection, an ISO standard for worldwide

communications that defines a networking framework for implementing protocols in seven layers

61


P POF Polymer Optical Fiber Protocol An agreed-upon format for transmitting data between two interfaces.

Q

R RS232 Recommended Standard-232, a standard interface approved by the

Electronic Industries Alliance for connecting serial devices

S

T Telematic Refers to the broad industry related to using computers in concert with

telecommunications system

U USB Universal Serial Bus

V

W WG_DA workgroup Device Architecture WLAN Wireless Local Area Network

X XML Extended Mark-up Language

Y

Z

62


References [1] Movimento Automotive, http://www.movimentoautomotive.com/, September 2005 [2] MOST Tutorial. [3] MOST Cooperation, MOST network,

http://www.mostcooperation.com/technology/network/index.php, September 2005 [4] MOST Cooperation, MOST Specification framework, Rev. 2.3,

http://www.mostcooperation.com/downloads/Specifications/, September 2005. [5] Optolyzer Manual [6] Pantera Manual [7] Form, Interpress, no 4, 2005, pp 58-61. [8] Noregon Systems, http://www.noregon.com/products/jpro_softing_api.asp, January 2006

63

http://www.movimentoautomotive.com/

http://www.mostcooperation.com/technology/network/index.php

Appendix A

Table of Contents A. Use Cases .............................................................................................................................. 2

A.1 UC1: Add a device .......................................................................................................... 2 A.2 UC2: Edit a device .......................................................................................................... 4 A.3 UC3: Configure a port..................................................................................................... 6 A.4 UC4: Run a test. .............................................................................................................. 8 A.5 UC5: Create a Test. ....................................................................................................... 10 A.6 UC6: View a Function Catalogue. ................................................................................ 11 A.7 UC7: View the MOST Signal Log. ............................................................................... 13 A.8 UC8: View the Network Peripherals............................................................................. 13

1

Appendix A

A. Use Cases

A.1 UC1: Add a device Scope: The Pantera application Level: User goal Primary Actor: Pantera User Stakeholders and Interests: - The Pantera User wants to add a PumaMOST device to the current Pantera project; used

for communication with a MOST network. Preconditions: A Pantera project is open. Postconditions: A PumaMOST device has been added to the current Pantera project. Basic flow:

1. User chose to add a new device from the main GUI. 2. System shows a GUI (a) with available devices. 3. User selects to add the PumaMOST device. 4. System shows the selected device. 5. User chose to configure the selected device. 6. System shows a GUI (b) with a default configuration for the selected device. 7. User chose to set the port type and port number as the physical port to communicate

through; e.g. USB port number one. 8. System shows the selected configuration 9. User chose to confirm the configuration. 10. System sets the selected configuration. 11. System closes the GUI (b) 12. System closes the GUI (a) 13. System adds the PumaMOST device to the main GUI with the selected configuration. 14. System creates a new “Port Configuration” (see UC3) 15. System adds the new “Port Configuration” to a GUI (c). 16. System returns to main GUI.

Alternative flows:

2-5a. User chose to cancel the process of adding of a new device. 1. User cancels the process. 2. System closes the GUI (a). 3. System returns to main GUI

6-9a. User chose to cancel the ongoing configuration of the device

2

Appendix A

1. User cancels the selected configuration. 2. System restores the default configuration. 3. System closes the GUI (b). 4. System returns to GUI (a). 5. System returns to basic flow 8

12-13a. User chose to cancel the process of adding of a new device. 4. User cancels the process. 5. System closes the GUI (a). 6. System returns to main GUI

Special Requirements: - None. Technology and data variations list: - Physical ports can be: USB, COM or WLAN. - See Appendix B1 and B2 for GUI prototypes. Frequency of occurrence: - Once for each PumaMOST that should be connected to a physical port in the project. Open Issues: - How to handle the situation when the user shows a combination of port type and port

number that is already occupied by another PumaMOST device in the current project? - How to handle the situation when the user selects an unsupported physical port?

3

Appendix A

A.2 UC2: Edit a device Scope: The Pantera application Level: User goal Primary Actor: Pantera User Stakeholders and Interests: - The Pantera User wants to edit a PumaMOST device in the current Pantera project; used

for communication with a MOST network. Preconditions: A Pantera project is open and a PumaMOST device has been added. Postconditions: A PumaMOST device has been edited or removed from the current Pantera project. Basic flow:

1. User selects the PumaMOST device to be edited from the main GUI. 2. System shows a GUI (a) with the current configuration for the device. 3. User chose to set the port type and port number as the physical port to communicate

through; e.g. USB port number two. 4. System shows the selected configuration. 5. User chose to confirm the configuration. 6. System sets the selected configuration. 7. System closes the GUI (a) 8. System updates the PumaMOST device in the main GUI with the selected

configuration. 9. System returns to main GUI.

Alternative flows: 1a. User chose to remove an existing PumaMOST device.

1. User selects the PumaMOST device to be removed from the main GUI. 2. User is prompted to confirm the removal.

1a. User chose to confirm the removal. 1. User chose “Yes” 2. System removes all configurations that may be related to the device, i.e. frequency, work mode, echo mode, port type and port number. 3. System removes all signals related to the device including the removal of

the signals from all GUIs where they exist. 4. System removes the chosen PumaMOST device from main GUI.

1b. User chose to cancel the removal. 1. User chose “No” 2. System cancels the removal.

2-5a. User chose to cancel the ongoing configuration of the device

4

Appendix A

1. User cancels the selected configuration. 2. System restores the default configuration. 3. System closes the GUI (a). 4. System returns to main GUI.

Special Requirements: - None. Technology and data variations list: - Physical ports can be: USB, COM or WLAN. - See Appendix B2 for a GUI prototype. Frequency of occurrence: - Once for each PumaMOST that should be connected to a physical port in the project. Open Issues: - How to handle the situation when the user shows a combination of port type and port

number that is already occupied by another PumaMOST device in the current project? - How to handle the situation when the user selects an unsupported physical port?

5

Appendix A

A.3 UC3: Configure a port Scope: The Pantera application Level: User goal Primary Actor: Pantera User Stakeholders and Interests: - The Pantera User wants to configure a PumaMOST port in the current Pantera project. Preconditions: A Pantera project is open and a PumaMOST device has been added. Postconditions: A PumaMOST port is configured in the current Pantera project. Basic flow:

1. User opens the GUI (a) from were he can configure available PumaMOST ports. 2. User chose to configure the selected PumaMOST port from the GUI (a). 3. System shows a GUI (b) with the default configuration for the PumaMOST port. 4. User chose to set the frequency in which the PumaMOST device should work. 5. System shows the selected configuration. 6. User chose to set the work mode, i.e. ”Master” or ”Slave”. 7. System shows the selected configuration. 8. User chose to set the echo mode, i.e. ”On” or ”Off”. 9. System shows the selected configuration. 10. User chose to enter a name for the base signals. 11. System shows the previously unnamed base signals with their newly assigned name. 12. User chose to confirm the configuration. 13. System sets the selected configuration. 14. System closes the GUI (b). 15. System updates the GUI (a) by changing the port from un-configured to be configured. 16. System returns to GUI (a).

Alternative flows: 3-12a User chose to cancel the configuration.

1. User cancels the selected configuration. 2. System closes the GUI (b). 3. System returns to GUI (a).

3-12b User chose to re-change a configuration. 1. User returns to any of the basic flows: 4, 6, 8, or 10.

3-12c User chose to keep the configuration. 1. User keeps the existing configuration. 2. System returns to basic flows 12

3-12d User choose to create user signals

6

Appendix A

1. User loads an existing XML file containing the function catalogue by browsing for it from an “Open Dialog”

2. System parses the loaded function catalogue and views it as a graphical tree in GUI (b)

3. User browses the graphical tree and select those operations that he want to create user signals for

4. User choose to add the selected operations 5. System adds the selected operations to the list of operations for which user signals

should be created 6. System returns to any of the basic flows 3, 4, 5, 6, 7, 8, 9, 10, 11 or 12

3-12e User choose to remove existing user signals 1. User chose to select those user signals that shall be removed, from the list of

“created user signals” in GUI (b). 5. System removes the selected user signals. 6. System returns to any of the basic flows 3, 4, 5, 6, 7, 8, 9, 10, 11 or 12

13a. User hasn’t assigned a valid name for the base signals. 1. System shows a GUI (c) with an error message that explains the cause to the error. 2. User chose to close the GUI (c). 3. System closes the GUI (c). 4. System returns to basic flows 10

Special Requirements: - None. Technology and data variations list: - See Appendix B3 for a GUI prototype. Frequency of occurrence: - At least once and every time the configuration needs to be changed. Open Issues: - None

7

Appendix A

A.4 UC4: Run a test. Scope: The Pantera application. Level: User goal Primary Actor: Pantera User Stakeholders and Interests: - The Pantera User wants to execute a test case; were MOST peripherals should be tested. Preconditions: - A Pantera project is open - A PumaMOST device has been added and configured in the current project. The device

must be configured as a “Slave”. - A PumaMOST port has been configured for the PumaMOST device in the current project. - A PumaMOST device is connected to the port. - A test case or test bench has been created for the current project. Postconditions: The test execution was run successfully. Basic flow:

1. User opens the GUI (a) from were he can run the test. 2. User chooses to run the test from the GUI (a). 3. System shows a GUI (b) with analysis information from the test. i.e. “System Log”,

“Signal Log”, Signal Graph” and “Execution Results”. 4. System connects to the PumaMOST device. 5. System updates GUI (b); “System Log”. 6. System set the “Blocking Time”, i.e. the time it will listen (block) for received MOST

control messages from the PumaMOST device before it aborts. 7. System updates GUI (b); “System Log”. 8. System sends the previously defined configuration to the PumaMOST device. i.e.

“Master/Slave”, “Echo On/Off” 9. System updates GUI (b); “System Log”. 10. System sends the predefined “RX Filter” setting to the PumaMOST device; which

defines the type of messages that will be received from the PumaMOST device. In our case it allows only MOST control messages.

11. System updates GUI (b); “System Log”. 12. System starts to listen for received MOST control messages. 13. System sends a predefined MOST control message to the PumaMOST device. 14. System updates GUI (b); “Signal Graph”. System repeats step 13-14 until all MOST control messages have been sent or test stops. 15. User chooses to stop the test. 16. System updates GUI (b); “System Log”. 17. System disconnects from the PumaMOST device. 18. System updates GUI (b) ; “System Log”, ”Signal Log” and ”Execution Results”.

8

Appendix A

19. User views the results in GUI (b) Alternative flows:

2-14a User chose to stop the test. 1. User stops the test. 2. System returns to basic flow 15.

4a An error message occurs when try to connect to the PumaMOST device. 1. System shows an error message in GUI (b); “System Log”. 2. System aborts the test.

6-10a An error message occurs when try to send configuration to the PumaMOST device. 1. System shows an error message in GUI (b); “System Log”.

12-14a A MOST RX control message is received. 1. System sends the message to GUI (b). 2. System updates GUI (b); “Signal Log”. 3. System starts to listen again for received MOST control messages.

12-14b A MOST TX control message is received. 1. System sends the message to GUI (b). 2. System updates GUI (b); “Signal Log”. 3. System starts to listen for received MOST control messages.

12-14c An error occurs when tried to send a MOST control message on the MOST network.

1. System shows an error message in GUI (b); “System Log”. 12-14d An error occurs when tried to read a MOST control message from the PumaMOST

device. 1. System shows an error message in GUI (b); “System Log”.

12-14eAn error occurs when tried to read a generated error message from the PumaMOST device.

1. System shows an error message in GUI (b); “System Log”. 12-14f The “Blocking Time” runs out of time and the user hasn’t chosen to stop the test.

1. System starts to listen for received MOST control messages. 13a An error occurs when try to send a MOST control message to the PumaMOST device.

1. System shows an error message in GUI (b); “System Log”. 17a An error occurs when try to disconnect from the PumaMOST device.

1. System shows an error message in GUI (b); “System Log”. 2. System aborts the test.

Special Requirements: - A PumaMOST must be connected to the MOST networks and to the PC. - A PumaMOST specific cable for communication between the PumaMOST and the PC - A MOST device must be connected to the MOST networks. - A MOST cable for communication between the peripherals on the MOST networks. Technology and data variations list: - None. Frequency of occurrence: - Could be nearly continuous. Open Issues: - None

9

Appendix A

A.5 UC5: Create a Test. Main Success Scenario: A Pantera User creates a test case in an E Script by using the built-in E Language and the available signals. Alternate Scenario: If an appropriate E Packet exists then it is used in the test case.

10

Appendix A

A.6 UC6: View a Function Catalogue. Scope: - The Pantera Application Level: - User goal Primary Actor: - Pantera User Stakeholders and Interests: - The Pantera User wants to view a Function Catalogue. Preconditions: - Pantera is started. - A valid function catalogue xml-file exists. Postconditions: - The function catalogue is successfully displayed. Basic flow:

1. The user clicks on the Tools menu. 2. A sub-menu appears. 3. In the sub-menu, the user chooses MOST and Function Catalogue. 4. The MOST Function Catalogue GUI window will appear. 5. The user clicks on the Load-button. 6. An Open File Dialog will be display. 7. The user locates and chooses to open a valid function catalogue xml-file on any of the

computer’s storage devices. 8. A parser in Pantera parses the information contained in the function catalogue xml-file

into a data structure. 9. The information in the data structure is shown as a browse-able tree in the MOST

Function Catalogue GUI window. Alternative flows: 4-6a. The user chooses to close the MOST Function Catalogue GUI window.

1. The system returns to basic flow 1. 7a. The user chooses to open an invalid xml-file.

1. The system shows a dialog with an error message. 7b. The user chooses the cancel to open an xml-file.

1. The system returns to basic flow 4. Special Requirements: - None. Technology and data variations list: - None.

11

Appendix A

Frequency of occurrence: - Could be nearly continous. Open Issues: - None. A Pantera User opens the MOST Function Catalogue GUI from within he browse the hard drive for the XML file that corresponds to the MOST function catalogue for the MOST network of interest. The file is then opened and parsed before it is shown on the screen as a browse-able tree hierarchy. The user then selects a desirable function which’s available parameter(s) appears on the screen. The parameters are entered and the user copies the generated string of hexadecimal values for the chosen functions to the E Script were a test case is created. See Appendix B4 for a GUI prototype.

12

Appendix A

A.7 UC7: View the MOST Signal Log. A Pantera User has run a test case and views the MOST Signal Log, were the MOST control messages is shown in a more readily way; compared to the Signal Log. See Appendix B5 for a GUI prototype.

A.8 UC8: View the Network Peripherals. A Pantera User opens the MOST Network Peripheral GUI in order to view the functionality offered by the connected MOST devices as well as the central register; holding the address table for all functions block on the network. See Appendix B6 for a GUI prototype.

13

Appendix B

Table of Contents B. GUI Prototypes ...................................................................................................................... 2

B.1. Device Dialog ................................................................................................................. 2 B.1.1 GUI Prototype........................................................................................................... 2 B.1.2 GUI Description ....................................................................................................... 2

B.2. MOST Device Configuration ......................................................................................... 3 B.2.1 GUI Prototype........................................................................................................... 3 B.2.2 GUI Description ....................................................................................................... 3

B.3. MOST Port Configuration .............................................................................................. 4 B.3.1 GUI Prototype........................................................................................................... 4 B.3.2 GUI Description ....................................................................................................... 4

B.4. MOST Function Catalogue............................................................................................. 5 B.4.1 GUI Prototype........................................................................................................... 5 B.4.2 GUI Description ....................................................................................................... 5

B.5. MOST Signal Log .......................................................................................................... 6 B.5.1 GUI Prototype........................................................................................................... 6 B.5.2 GUI Description ....................................................................................................... 6

B.6. MOST Network Peripherals ........................................................................................... 7 B.6.1 GUI Prototype........................................................................................................... 7 B.6.2 GUI Description ....................................................................................................... 7

1 mars 2006

Appendix B

B. GUI Prototypes

B.1. Device Dialog

B.1.1 GUI Prototype

Figure B1: A Device Dialog

B.1.2 GUI Description The User brings up this dialog whenever he wants to add a new device. The user selects the type of device that he wishes to add, by selecting it from the combo box. As a result of this; a default name is set in the text field labelled “Name”. The default name is set to “PumaMOST” of this is the first PumaMOST device in the project, “PumaMOST1” if it is the second one, “PumaMOST2” if it is the third on and so on. The user may manually change the default name if he wishes to do so. The “Device Configuration” dialog (see figure B2) is opened when the user clicks at the “Configure” button from were it is possible to configure the selected device. The user may abort this process by clicking at the “Cancel” button.

2 mars 2006

Appendix B

B.2. MOST Device Configuration

B.2.1 GUI Prototype

Figure B2: A Device Configuration Dialog

B.2.2 GUI Description The user brings up this dialog from the “Device” dialog (see figure B1) when he clicks at the “Configure” button. The user selects the port and port number used for communication with the PumaMOST device. This is done by first selecting the port type by clicking at the one of the radio buttons and then chose the port number from the combo box. The network configuration is accessible from the “View Network Peripherals” button, (see figure B6). The configuration is confirmed or aborted when clicking at the “Ok” respective “Cancel” button.

3 mars 2006

Appendix B

B.3. MOST Port Configuration

B.3.1 GUI Prototype

Figure B3: A MOST Port Configuration Form

B.3.2 GUI Description The user brings up this form whenever he wants to configure the physical port connected to the PumaMOST device or build signals; i.e. base signals and most specific user signals created from the function catalogue. The user configures the PumaMOST by clicking at the radio buttons in the upper left corner. The necessary base signals are named by entering a name for them in the text field next to the label “Base Name”; i.e. tree different signals with the suffixes: “.tx”, “.tx_ack” and “.rx”. The user may also build specific user signals from a function catalogue, for those operations that he wants to be executed on a MOST device. This is done by clicking at the “Load” button, which in turn, brings up a standard open dialog, from where it is possible to browsing for the file. After loading the function catalogue it is possible to browse the tree for a specific operation and adding it to the signals selected for a later creation upon confirmation when the form is closed. When the user chose to click at the “Ok” button, the configuration is validated, signals are built and the GUI closed. The user may chose to close the GUI with all existing configurations and signals prevailed by clicking at the “Cancel” button

4 mars 2006

Appendix B

B.4. MOST Function Catalogue.

B.4.1 GUI Prototype

Figure B4: A MOST Function Catalogue Form

B.4.2 GUI Description The Most Function Catalogue Dialog is displayed from a tools menu in Pantera. In this dialog the user can load a function catalogue XML file by clicking on the Load button in the upper left corner. When a valid XML file has been loaded its function blocks, functions and operations are displayed in a browse-able tree. By clicking on an operation in the tree, the parameters and their information for the actual operation will be listed in the list on the right. The user has the possibility in an easy way to build hexadecimal MOST-frames in this dialog. This is done by clicking on a wanted operation in the tree, adding values to any of its parameters, and finally setting instance, source- and target-addresses.

5 mars 2006

Appendix B

B.5. MOST Signal Log

B.5.1 GUI Prototype

Figure B5: A Signal Log Frame.

B.5.2 GUI Description The user may chose to view the MOST specific Signal Log after a test case has been run. Most Control Messages sent and received are interpreted in more acceptable way seen from a user perspective. The Source Address, Target Address, Function Block, Function and Operation Type are viewable as text or hex values. All other values are shown as hex values.

6 mars 2006

Appendix B

B.6. MOST Network Peripherals

B.6.1 GUI Prototype

Figure B6: A MOST Network Peripherals Form.

B.6.2 GUI Description The user brings up this form from the “Device Configuration” dialog (see figure B2) when he clicks at the “View Network Peripherals” button. The user starts with clicking at the “Load” button for browsing after a function catalogue associated with it. The file name for the chosen catalogue is the written in the text field next to the “Load” button as a reminder of which catalogue that is loaded. Then whenever the user clicks at the “Update” button; a request is taking place for the available functions, central registry, and device information on the network connected for this physical port and presented in the GUI. The user may close the form by clicking at the “Close” button.

7 mars 2006

Appendix C

Table of Contents C. System Test Specification ..................................................................................................... 2

ST1 – Add a device ................................................................................................................ 2 ST2 – Edit a device ................................................................................................................ 2 ST3 – Configure a Port........................................................................................................... 3 ST4 – Run a test ..................................................................................................................... 4 ST5 – View a Function Catalogue ......................................................................................... 5 ST6 – View the MOST Signal Log........................................................................................ 5 ST7 – View the MOST Network Peripherals......................................................................... 5

1

Appendix C

C. System Test Specification

ST1 – Add a device 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R1.1, R1.2, R1.3, R1.4, R1.5. 3. Estimated time for test: less than 10 minutes. 4. Execution:

a. Test that a PumaMOST device can be added. b. Test that a default configuration is set when the MOST Configuration GUI is

displayed after a MOST device precisely has been added. c. Test that the MOST Configuration GUI has support for selection of USB,

COM or WLAN as physical port. d. Test that selections are neglected when cancel in MOST Configuration GUI is

made. 5. Expected outcome:

a. A PumaMOST device is added as a sub-item to ‘This Computer’ in the Device Manager tab.

b. A default configuration is shown. c. Selection of USB, COM or WLAN is possible to perform. d. Changes made when cancelling, are not stored.

ST2 – Edit a device 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R2.1, R2.2, R2.3, R2.5. 3. Estimated time for test: less than 10 minutes. 4. Execution:

a. Test that a PumaMOST device can be edited. b. Test that when opening an existing PumaMOST device, the configuration is set

up as the last configuration made on the device. c. Test that the MOST Configuration GUI has support for selection of USB,

COM or WLAN as physical port when editing a PumaMOST device. d. Test that selections are neglected when cancel in MOST Configuration GUI is

made. 5. Expected outcome:

a. The MOST Configuration GUI appears when the user chooses to edit a PumaMOST device.

b. The configuration last done to the PumaMOST device is displayed. c. Selection of USB, COM or WLAN is possible to perform. d. Changes made when cancelling, are not stored.

2

Appendix C

ST3 – Configure a Port 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R3.1, R3.2, R3.3, R3.4, R3.5, R3.8, R3.9, R3.10, R3.11, R3.12,

R3.13, R3.14. 3. Estimated time for test: 15 minutes. 4. Execution:

a. Test that configuration of a physical port is possible for an added PumaMOST device is possible.

b. Test that a default configuration is set when the MOST Physical Port Configuration GUI is displayed after a PumaMOST device precisely has been added.

c. Test that the MOST Port Configuration GUI has support for selection of supported frequencies.

d. Test that the MOST Port Configuration GUI has support for selection of supported work modes.

e. Test that the MOST Port Configuration GUI has support for selection of supported echo modes.

f. Test that the MOST Port Configuration GUI has support for displaying an imported and parsed function catalogue in a tree-structure.

g. Test that base signals used for MOST control messages have been created and exist after configuration of the MOST port.

h. Test that user-signals can be added via the function catalogue. i. Test that the base signal name only can start with a letter, and one, none or

several digits/letters follows. j. Test that already existing signal names can’t be added. k. Test that an existing port configuration can be edited. l. Test that selections are neglected when cancel in MOST Port Configuration

GUI is made. 5. Expected outcome:

a. The MOST Port Configuration GUI appears when the user chooses to edit the MOST port.

b. A default configuration in the MOST Port Configuration GUI is shown. c. Selection of the frequencies 44.1 and 48 kHz is possible. d. Selection of the work modes slave and master is possible. e. Selection of the echo mode on and of is possible. f. MOST Port Configuration GUI displays the imported and parsed function

catalogue in a tree-structure. g. Base signals are added. h. User-signals are added. i. Error message when an invalid name is entered. j. Error message when it already exists a signal with the name. k. Choosing to edit an already configured MOST port displays the MOST Port

Configuration GUI. l. Changes med when cancelling are not stored.

3

Appendix C

ST4 – Run a test 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R4.1, R4.2, R4.3, R4.4, R4.5, R4.6, R4.7, R4.8, R4.9, R4.10,

R4.11. 3. Estimated time for test: 20 minutes. 4. Execution:

a. Test that MOST control messages can be sent/received from within an E-Script by using MOST specific signals.

b. Test that MOST control messages can be sent/received from within an E-Script by using MOST specific E-Packets.

c. Test that E-Packets for MOST can be used from within an E-Script. d. Test that the System are able to send and receive raw MOST control messages. e. Test that the System Log logs the execution of events and errors that occur. f. Test that sent MOST control messages are echoed when the echo mode is

turned on. g. Test that the System logs MOST control messages in the Signal Log during

run-time. h. Test that the System logs MOST control messages in the Execution Results

after the test has been stopped or aborted. i. Test that a test can be stopped. j. Test that a test can be aborted. k. Test that the System aborts the execution of a test when the connection to the

PumaMOST device fails. l. Test that the System aborts the execution of a test when the configuration of

the PumaMOST device fails. 5. Expected outcome:

a. MOST control messages can be sent/received from within an E-Script by using MOST specific signals.

b. MOST control messages can be sent/received from within an E-Script by using MOST specific E-Packets.

c. E-Packets can be used from within an E-Script. d. The System is able to send and receive raw MOST control messages. e. The System Log logs events and errors that occur during execution. f. Sent MOST control messages are echoed. g. The Signal Log logs MOST control messages during run-time. h. MOST control messages that were sent/received are displayed in the Execution

Results log. i. The test is stopped. j. The test is aborted. k. The execution of the test is aborted. l. The execution of the test is aborted.

4

Appendix C

ST5 – View a Function Catalogue 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R5.1, R5.2, R5.3, R5.4. 3. Estimated time for test: 10 minutes. 4. Execution:

a. Test that different Function Catalogue xml-files can be opened. b. Test that the contained function blocks, functions, operations and parameters in

a Function Catalogue xml-file can be viewed in the MOST Function Catalogue GUI.

c. Test that an error message is displayed when trying to open an invalid Function Catalogue xml-file.

5. Expected outcome: a. Different Function Catalogues can be opened. b. The MOST Function Catalogue GUI displays the contained function blocks,

functions, operations and parameters contained in the opened Function Catalogue.

c. An error message is displayed.

ST6 – View the MOST Signal Log 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R6.1 3. Estimated time for test: less than 5 minutes. 4. Execution:

a. Test that the execution results for MOST control messages can be read in the MOST Signal Log GUI.

5. Expected outcome: a. The execution results of MOST control messages can be read in the MOST

Signal Log GUI.

ST7 – View the MOST Network Peripherals 1. Testbench: C++, Win XP Pro 2. Tested Requirements: R7.1, R7.2, R7.3. 3. Estimated time for test: 4. Execution:

a. Test that devices and their functionality currently attached to the MOST network, can be viewed in the MOST Network Peripherals GUI.

b. Test that the addresses for devices currently attached to the MOST network, can be read in the MOST Network Peripherals GUI.

c. Test that the manufacturing information of a device currently attached to the MOST network, can be read in the MOST Network Peripherals GUI.

5. Expected outcome: a. Attached devices and their functionality are displayed in the MOST Network

Peripherals GUI. b. Addresses of attached devices are displayed in the MOST Network Peripherals

GUI. c. Manufacturing information of attached devices are displayed in the MOST

Network Peripherals GUI.

5

Appendix D - MOST Manual.doc Copyright by Movimento Created on 2/14/2006 12:04 PM

PanteraTM MOST Device Manual

Appendix D - MOST Manual.doc Copyright by Movimento Page 2 (14)

Document History

Version Date Section Comment on changes

1.0 A 2006-02-27 - First version


Table of Contents

1 MOST introduction ................................................................................5 2 MOST preparations ...............................................................................6 3 MOST Device Configuration..................................................................7

3.1 MOST Device Configuration Setup............................................................ 7 4 MOST Physical Port Configration..........................................................9

4.1 PumaMOST Settings................................................................................. 10 4.2 Base Signals .............................................................................................. 10 4.3 Associated Function Catalogue................................................................. 11 4.4 MOST Physical Port Configuration .......................................................... 12

Appendix D - MOST Manual.doc Copyright by Movimento Created on 2/14/2006 12:04 PM

1 MOST introduction

This help file describes how to set up a communication with MOST devices on a MOST network in Pantera. It will make it possible to send and receive MOST control messages in virtual signals from Pantera through one of the port types: USB, COM or WLAN, via the PumaMOST device; a hardware supplied by Movimento.

Media Oriented Systems Transport (MOST) is a system with single-master capability, i.e. all nodes in the network are able to transmit data but must first wait to get a green light from the master.

The data sent on a MOST network is encapsulated in a MOST frame. Each frame consists of 64 bytes, and each 64-bytes frame consists of 2 bytes of control message data. Frames are transferred on the MOST ring at a 44.1 or 48 kHz rate.

A transmitter can send a message to a single node, group of nodes or to all nodes (broadcasting).

The MOST device supports logging and generation of MOST frames. The PumaMOST does though lack support of acting as a spy, i.e. it is not possible of logging control messages that are not directly addressed to the PumaMOST device.

The configuration of one of this device in Pantera consists of two steps, the device configuration where the configuration of the physical communication with the PumaMOST is made, and the port configuration where specific settings for each of the channels are made.


2 MOST preparations

In order to use this device the following must have been taken

• The MOST device package must have been installed in Pantera

• The MOST hardware drivers must have been installed


3 MOST Device Configuration

The MOST device has to be configured before it can be used for communication between the Pantera and PumaMOST. This is done in the MOST Device Configuration Dialog.

3.1 MOST Device Configuration Setup

To setup the PumaMOST device the following steps have to be performed:

1. In the Project View (Figure 1), click on the Hardware icon. This will bring up the Hardware tab (Figure 2).

Figure 1:

2. Add a MOST device by right-clicking at ‘This Computer’ (see Figure 2) and choose to Add and Add Device in the sub-menus, which brings up the Device Dialog.

Figure 2:


3. In the Device Dialog (Figure 3) the name and type of device are chosen. Enter an appropriate name of the device in the text field “1”, labeled “name” and then select the “MOST device” from the combo box “2”, labeled “type”. Then proceed with clicking on the ‘Configure’-button which will bring up the MOST Device Configuration dialog.

Figure 3:

4. In the MOST Device Configuration dialog (figure 4), select the physical port to be used, e.g. USB, COM or WLAN by clicking at one of the radio buttons and then selecting the corresponding channel number from the combo box; no channel number can be selected when the port type WLAN is selected.

5. Finish by clicking on the ‘OK’-button.

Figure 4:

When a device has successfully been added, it can be seen as a sub-item to ‘This Computer’ as shown in figure 5 below.

Figure 5:


4 MOST Physical Port Configration

The setup of signals is made in the MOST Physical Port Configuration dialog.

The MOST port configuration dialog consists of three fields (see Figure 6), they are: PumaMOST Settings (green area), Base Signals (yellow area) and Function Catalogue (red area).

Figure 6:


4.1 PumaMOST Settings

The configuration of the PumaMOST device is made in the PumaMOST settings group. Configurable parameters are: Frequency, Work Mode and Echo Mode, as shown in figure 7.

Figure 7:

By setting the frequency the user can chose the frequency in which the PumaMOST device operates when sending and receiving messages on the network.

By setting the work mode the user can chose the ‘mode’ in which the PumaMOST device should operate. Set it as ‘Master’ if it should act as the ‘Network Master’, otherwise chose the mode ‘Slave’

By setting the echo mode the user can chose to request acknowledgement from the PumaMOST device for messages sent on the network. An acknowledge will be given when turned on, otherwise not.

4.2 Base Signals

The base signals are three virtual signals that will turn up in Pantera and represent the entire PumaMOST bus, i.e. all signals that are MOST control messages. They do not only handle a certain kind of control messages. There will always be three generated base signals with the same name entered in the text field “1”, but with different suffixes (rx, tx or tx_ack) as shown in the column “2” in the list in figure 8. The “rx” signal handles received MOST control messages the “tx” signal handles the transmitted ones and the “tx_ack” signal handles messages acknowledged by the PumaMOST device when sent on the network. For every base signal there will exist a data type as shown in column “3”, it contains the parameters needed when using base signal to send or receive a MOST control message. For example, by displaying a base signal’s “rx” signal (received messages) in the log when running a test, the result will be that all received MOST control messages will appear in the log window.

Figure 8:


4.3 Associated Function Catalogue

A way of ease the usage of signals is to create user specific signals for only those operations to be executed. This will extract the need of entering the Function Block id, Function Id and Operation Type. This is done by loading the function catalogue associated with the MOST network from a XML file, then browse and select the operations of interest in the generated tree

Figure 9:

The loading of a Function Catalogue is done by clicking at the “load” button in the upper left “1”. When a valid Function Catalogue has been loaded a tree-view will be displayed “2”, with the function blocks, functions and operations contained in the XML file.

For each added user signal, three kind of signals will be created and put in the Signals Selected list “3”. The signal names for the user signals are constructed from the function block-, function- and operation-name, but with different suffixes. The “rx” signal handles received MOST control messages the “tx” signal handles the transmitted ones and the “tx_ack” signal handles messages acknowledged by the PumaMOST device when sent on the network. The data types for the user signals can be seen in the second column in the Signals Selected list “3”.


4.4 MOST Physical Port Configuration

To setup the MOST device port perform thefollowing steps have to be performed:

1. In the Project View (Figure 10), click on the Configuration icon. This will bring up the Configuration Manager below the Project View (Figure 11).

Figure 10:

2. Add a new configuration by clicking on the leftmost icon (see figure 11). This will make a Configuration and a icon with a green dot on appear.

Figure 11:

3. Double-click on the new Configuration icon to bring up the Configuration window (see figure 12) onto the right.

4. Clicking on the Test Probe Harness icon “1” (see figure 12) will display the Test Probe Harness – Layout window (see figure 13).


Figure 12:

5. Available ports are shown on the left “1”. Adding a harness to a port is done by double-clicking on the name in the Available Ports list, which will transfer the port to the probe’s list on the right.

6. This icon in the Probes list will display that a probe has been added but not yet configured. Configuration of the probe is done by double-clicking on it, this will result in the display of the MOST Physical Port Configuration window (figure 14).

Figure 14:


7. Set the frequency, work mode and echo mode setting for the PumaMOST with the radio buttons in the upper left.

8. Set the base name for the base signals. Valid base names starts with a letter, followed by none or several letters or digits. ‘Unnamed’ which is filled in when window is displayed at first, is a non-valid name.

9. If you want to add your own signals a function catalogue (valid XML file) has to be present. It is loaded by clicking on the “Load” button and by choosing a XML file. If the XML file is a valid function catalogue, a tree with the function blocks, functions and operations will be displayed

10. User signals is added either by double clicking on an operation (one of the last leaves in the tree) or by selecting one or several operations followed by clicking on the arrow pointing right. Signals that have been added are shown in the Signals Selected list

Interfacing MOST networks from Pantera - Com Hemweb.comhem.se/~u37600264/files/exjobb_cth.pdf ·...

Documents

Transcript of Interfacing MOST networks from Pantera - Com Hemweb.comhem.se/~u37600264/files/exjobb_cth.pdf ·...