Translation of CAN Bus XML Messages to C Source Code

(1)

Author:

Gustav Andersson

Supervisor:

Dr. Kostiantyn Kucher

External Supervisor:

Fredrik Björn

Semester:

Spring 2020

Subject:

Computer Engineering

Engineering Degree Project

Translation of CAN Bus XML

Messages to C Source Code

(2)

Abstract

The concept of translating source code into other target programming languages is extensively used in a wide area of applications. Danfoss Power Solutions AB, a company located in Älmhult, strives to streamline their way of software develop-ment for microcontrollers by impledevelop-menting this idea. Their proprietary software tool PLUS+1 GUIDE is based on the CAN bus communication network, which al-lows electronic control units to share data represented in the XML format. Due to compatibility problems, the application in the electronic control units requires this data to be translated into the source code in the low-level C programming language. This thesis project proposes an approach for facilitating this task by implementing a source-to-source compiler that performs the translation with a reduced level of man-ual user involvement. A literature review was conducted in order to find the existing solutions relevant to our project task. An analysis of the provided XML input files was thereafter performed to clarify a software design suitable for the problem. By using a general XML parser, a solution was then constructed. The implementation resulted in a fully functional source-to-source compiler, producing the generated C code within a time range of 73–85 milliseconds for the input test files of typical size. The feedback received from the domain experts at Danfoss confirms the usability of the proposed solution.

Keywords: compiler, transpiler, source-to-source compiler, XML, C program-ming language, parser, CAN bus, electronic control unit

(3)

Preface

This thesis project would not have been possible to complete without the involvement of the two supervisors that supported me along the way. Therefore, I would like to ex-press my gratitude to you. Many thanks to my external supervisor Fredrik Björn, for making this work possible, and for a successful cooperation with Danfoss Power Solu-tions AB. I would also like to thank my university supervisor Dr. Kostiantyn Kucher for the continuous guidance throughout the project. I am grateful for all of the materials and tips that you provided me with, and especially for your help regarding the report writing.

(4)

1 Introduction

During software development, certain programming tasks can sometimes be repeatable and thus have the consequence of producing similar code. The company Danfoss Power Solutions AB relate to this fact in their process of manual translation of data formatted in XML into the corresponding code in the programming language C. This approach is inefficient due to the wasteful time consumption, and also because of the errors that nor-mally occur when programming in such a low-level language. Therefore, Danfoss would like to explore the possibility to address this problem by implementing a solution based on a compiler construction approach, which would automatically perform the code trans-lation. This thesis project reflects how a solution was accomplished to solve this issue, i.e., reviews of the existing XML parsing and compiler construction approaches, analysis of the provided input XML files, implementation of the source-to-source compiler, and the obtained results.

1.1 Background

Danfoss Power Solutions AB is a part of Danfoss A/G, which is one of the leading produc-ers of electronic control systems for electrical and hydraulic propel and work functions in off-highway vehicles. The department in Älmhult is developing and maintaining a tool called PLUS+1 GUIDE, which is an advanced software tool suite for control system de-sign, test, and simulation [1]. An essential part of electrical control systems in vehicles is the CAN bus communication network [2,3], which allows electronic control units to share data. The CAN bus is also used for vehicle diagnostics and firmware updates. The data sent in the CAN messages are described in an electronic specification in XML format [4]. The XML file contains information about what CAN messages the node will receive and transmit, and what signals are included in each CAN message. Those signals describe various electronic control unit attributes such as speed, pressure, etc. The sizes of the XML files typically range from several kilobytes to several hundred kilobytes.

1.2 Related work

Aho et al. [5], Grune et al. [6], and Stanier and Watson [7] similarly present the stan-dard compiler construction approach by describing the entire process of translating an input character stream into the corresponding target machine code. Work by Parr [8, 9] introduces the compiler-related parser generator tool ANTLR that can be used to design a grammar with lexical and syntactical rules for input texts (e.g., source code files), and thereafter generate a parser that produces a traversable parse tree or abstract syntax tree for the given input text. A survey in the form of a Systematic Literature Review by Basti-das and Pérez [10] presents multiple relevant works where source-to-source compilers have been used in different projects. The literature review in Chapter 2 further describes all of the main concepts within this area, based on various related works.

1.3 Problem formulation

The application in the electronic control unit requires the data from the XML file to be presented in C source code [11]. Translating the XML code into C source code is cur-rently performed manually, and there are expectations that this could become an auto-mated process. Thus, Danfoss would like to investigate if it is possible to implement a compiler [5] for carrying this task out automatically in the background without manual

(6)

involvement. The objective is therefore to investigate, design, and implement a software solution, namely, a compiler that will automatically interpret and generate the C source code given the input electronic data sheet in XML, both for incoming and outgoing CAN messages. The expected outcome of the degree project is a prototype of a functional com-piler that automatically performs the translation process from XML to C source code for electronic control units.

1.4 Motivation

The process of manual translation of source code into other coding languages is a time consuming and error-prone task. Therefore, companies like Danfoss would most likely benefit from surrendering the traditional way and instead making use of automated so-lutions that would speed up the software development. In this case, such a solution comprises a compiler that is externally invoked to perform the code transformation. A successful solution could in that case be integrated to the PLUS+1 GUIDE [1] software to counteract the aforementioned problems. Other companies with similar problems could use this work as an inspiration in the future.

1.5 Objectives

The objectives set for this thesis project are included in Table 1.1.

Table 1.1: Thesis project objectives

O1 Conduct literature review of existing compiler construction approaches O2 Implement the compiler

O3 Run test cases with different input data to test the compiler O4 Evaluate memory and time consumption

The first objective O1 will be useful to get the essential knowledge of how compilers are constructed in general, and to get inspiration from the existing approaches that have been applied in other related works with similar problems. The objective O2 can then be initiated, which will include the tasks of analyzing the XML files provided by Danfoss and implementing the software solution. To address the objective O3, the produced ap-plication will be accordingly tested and validated against some real-world input data to verify the expected behaviour. Lastly, the aim of the objective O4 will be to carry out a performance evaluation based on the experiments with input files of varying size.

1.6 Scope/Limitation

To limit the scope of the thesis project, only the particular XML schema definition file provided by Danfoss will be used. The compiler will in other words be based on the structure of the specific XML files that use this schema. Hence, the implementation will be specifically designed for the software that Danfoss is using, and not a general solution.

1.7 Target group

Although this work is specifically tailored for Danfoss, the concept covers various parts that could be inspirational and useful for other audiences. More specifically, it aims for the target group of practitioners working with the CAN bus systems that also exchange data

(7)

specified in the XML format, which has to be further translated into the C programming language code.

1.8 Outline

Chapter 2 provides a description of the approaches to solve the problem. Firstly, a litera-ture review will be presented; both to learn the theoretical basics within the area, and to get an understanding of what has previously been accomplished in related works. Lastly, the design and implementation process to be followed will be presented, with a planning on how to achieve the set of goals.

Chapter 3 describes the software implementation in detail. It is introduced with an analysis of how the input file should be interpreted and thereafter continued with a deeper explanation of all the tasks included in the developed software.

Chapter 4 presents all of the consequential results of the developed program. It will include examples in the form of figures, presenting the generated output files from various input files. Finally, a performance evaluation including both time and memory consump-tion will be presented.

Chapter 5 includes an analysis of the results that were presented in Chapter 4. The results of the performance evaluation will be discussed, for instance by analysing how the implementation performs when handling files of varying size. This chapter will addition-ally include a domain expert feedback by the external supervisor at Danfoss; by validating the program and provide suggestions for improvements.

Chapter 6 discusses what has been accomplished in this work and whether the problem could be solved differently.

Finally, Chapter 7 summarizes this work and outlines the potential future work outside the scope of the thesis project.

(8)

2 Method

This chapter begins with a literature review of existing approaches when it comes to the construction of compilers. Initially, the standard compiler construction approach will be explained and discussed, followed by an introduction of the XML format and XML Schema. The final section within this review presents related works where source-to-source compilers proved to be useful. The chapter continues with sections describing the design and implementation process to be followed during the project, and how the solution will be validated. Furthermore, reliability and validity concerns will be discussed, as well as ethical considerations.

2.1 Literature review

2.1.1 Standard compiler construction approaches

During the process of software development, compilers are involved in the background without us knowing. Probably everyone within this field of science is familiar with this concept. For instance, a program has been developed by writing source code in some pro-gramming language. To run this program, it has to be compiled. Briefly explained, what happens is that the source code is shipped to an intermediary that processes the code and translates it into the corresponding code of the target language. Different programming languages require different target languages or code representations. The source code in low-level programming languages such as C [11], C++ and Go is typically translated into machine code, whereas the source code in high-level programming languages like C# [12] and Java is typically translated into portable byte code. Except for just translat-ing the source code statement-by-statement, a compiler usually also searches for errors that could terminate the process and also applies optimizations in many cases. A flawless input program results in a translation of the code that can be successfully executed by the computer. In this section, different standard compiler construction approaches will be presented and discussed.

In compiler construction, there are a lot of tasks going on behind the scenes. The standard approach of compiler construction includes several steps. Related work from different literary sources ends up in the same explanation with almost identical steps re-garding the construction of a compiler.

Aho et al. [5], Grune et al. [6], and Stanier and Watson [7] divide the various phases as Figure 2.1 describes. In a general way, compiler construction is categorized into two sections: the frontend and the backend. As described by Grune et al. [6], the frontend part is responsible for the analysis of the input program; whereas the backend generates the equivalent target language code. The initial phase of the compiling process is called lexical analysis. As Aho et al. [5] explain, the lexical analyzer receives the stream of characters building up the source code. The analyzer further processes the input stream by grouping it into so-called lexemes. Each of those will consequently get a corresponding tokenas output. For instance, initializing a variable, e.g., “x = 0;”, will result in a token for each one of the lexemes. The lexeme x is mapped into the token type identifier. Since this is a variable name, it also has to be reserved a slot in a symbol table, which will be utilized in future phases. The lexeme = is mapped into the token type operator, the lexeme 0 is mapped into the token type literal, and the lexeme ; is mapped into a token of type separator.

The tokens provided by the lexical analyzer will be forwarded to the next phase of the process, called the syntax analyzer. With regards to the grammatical structure of the

(9)

character stream Lexical analyzer Syntax analyzer Semantic analyzer Optimization passes Code generator target-machine code tokens syntax tree frontend backend IR IR

Figure 2.1: The included steps defining the structure of a compiler (based on the work by Stanier and Watson [7]).

received tokens, it analyzes and reproduces a corresponding program in the form of a tree, known as the syntax tree (the terms parse tree and abstract syntax tree are also used in some contexts). As further explained by Aho et al. [5], each token will be represented by the corresponding node in the tree.

The generated syntax tree is sent to enter the next phase, called the semantic analyzer. By combining the syntax tree with the symbol table, the semantic analyzer can examine the semantic consistency of the input program. A typical task performed by the semantic analyzer is called type checking. For instance, this could be to check if the operands of an arithmetic operator are of the same data type and possibly correct them to get consistency. After the previous phase of consistency checks and corrections, an intermediate rep-resentation (IR)is generated. The IR can be utilized to perform optimizations of the target code to be generated. This includes improvements in the form of shorter and cleaner code, but also faster code. Depending on how important the optimizations of the source pro-gram is considered to be, the complexity of the phase varies. Aho et al. [5] conclude that the compilers that are very optimization-oriented spend a notable amount of time during this phase, but it could make noticeable improvements of the target code relative to the compilation time. Finally, this IR is sent to the last step of the process, namely the code generationphase. The code generator will take care of the optimized code and generate the corresponding target code, e.g., x86 binary code for the GNU/Linux operating system. The standard compiler construction approach is truly useful and suitable when it comes to the task of producing an equivalent target code of an input source program. However, this approach is not entirely motivated in this project, since the provided XML files include some data that is not of immediate interest for our task, i.e., the data that

(10)

should not be translated to the target code. With this in mind, a conclusion can be drawn that the target code should not be exactly equal to the input data. A more suitable op-tion would be to design it to just extract the data of importance and avoid processing the unnecessary data. Furthermore, the XML input files lack some data, which would make the standard compiler construction approach produce incomplete target code. No matter which approach to follow, this project will have to make use of some hard-coded infor-mation to generate the target code for the data missing in the XML input files. Based on the stated problems, the intention will be to rely on an existing XML parser library, rather than starting with low-level lexical and syntactical analyses.

2.1.2 Parsing and analysis of XML data

The Extensible Markup Language, more commonly referred to as the XML format [4], is a markup language that was developed to structure data in a readable way for both humans and machines. The usage of XML facilitates the data exchange between various computer systems. For instance, some computer systems use formatted data that is not compatible with the formats from other systems. By translating such data into XML format before sending, the receiving end can interpret the data seamlessly and therefore avoid potential formatting problems. The XML data is arranged in a hierarchical structure, consisting of tags describing the data.

Figure 2.2: The structure of an XML document.

As seen in Figure 2.2, the syntax of XML is self-describing, making the user able to model the content freely. For instance, tags with other names could be added easily, as long as they follow the tree-like structure; files following the correct syntax are called well-formedXML documents. The freedom that XML offers could in some cases result in problems since there are no rules for what content can be included. For instance, if

(11)

two computer systems are communicating by exchanging data with the XML format, the receiving end might encounter data that it had not expected to get. To get rid of this problem, XML documents are sometimes prompted to obey a set of instructions, namely the XML Schema Definition (XSD) [13]. An XML Schema consists of rules defining the allowed structure of an XML document. It could be restrictions on what elements and attributes are permitted to be included, what data types it should have, and in which order the elements should be organized. In this way, the XML document can follow such rules, and ensure that it only contains the legal components defined in the XML Schema.

Figure 2.3: The structure of an XML Schema (XSD).

Similar to the XML format, an XML Schema is also based on a hierarchical structure consisting of tags. Figure 2.3 represents the corresponding XML Schema for the XML example in Figure 2.2. By examining the XML Schema, it can be seen that some rules are applied. For instance, every element within the <city> tag in the XML document must have the specified order defined within the <xs:sequence> tag in the XML Schema. Furthermore, every element within the <city> tag in the XML document must be of the string data type. Additionally, elements using other names than the ones defined in the XML Schema will be disapproved.

In this work, the XML files are the main documents that include the data of impor-tance. To extract and make use of this information with a programming language, a parsingtechnology will be needed. As discussed by Lam et al. [14], the standard parsing approaches developed specifically for the XML format involve either token stream events (SAX and StAX parsers) or structured XML data models (VTD and DOM parsers).

As opposed to the solutions initially designed and limited to the XML format, we can also consider the approaches following the traditional compiler construction workflow. The related work by Parr [8,9] introduces a software tool called ANTLR, which is a parser generator that serves the purpose of reading, processing, executing, and translating text. A so-called grammar is designed to define the syntactical rules for input text documents, and thereafter generate a parser which produces a traversable parse tree. Parr further provides an example of how to use ANTLR to build an XML parser. By mimicking the grammar rules from the standard XML language definition, a corresponding grammar in ANTLR can be constructed. Typically, there exist two separate grammars: the lexer grammar and the parser grammar. The lexer grammar is required to define rules for tokenizing each character of the input stream. These tokens will later be utilized by the parser grammar, whose purpose is to define the more tree-like structure rules for the input stream. With

(12)

two fully designed grammars, everything is set to produce parse trees for the desired XML files.

Perkins et al. [15] describe an approach of how to generate efficient parsers through direct compilation of XML Schema grammars. The traditional solutions for XML parsing and validation according to XML Schema typically treat these as two separate processes. At first, a parsing process would take place (with only limited well-formedness checks), and then a validation process would be applied to the output of the parser. This approach results in the validation process being computationally expensive, and thus often disabled in practice. A possible alternative would be to use a grammar-based approach for gener-ating efficient validgener-ating XML parsers, but such existing solutions reviewed by Perkins et al. had shortcomings related to the support of various XML and XML Schema features. Thus in their work, Perkins et al. propose their own grammar-based approach which uses the XML Schema components—defined in the XML Schema Recommendation doc-ument/standard from W3C—as the basis instead of relying on a custom grammar as well as custom intermediate representations. This approach has proved to be very efficient in comparison to the existing open-source parsers, as it allows for a single scanning of the input data, during which parsing and validation could operate simultaneously. However, this approach aims to support generation for XML Schema to the maximal extent, which is overkill in the case of our work—our solution is only expected to support a limited num-ber of XML features used in the data provided by Danfoss. Additionally, the approach of Perkins et al. is only capable of producing parsers in C and Java, which are programming languages that will not be used for the development of the compiler in this work due to external requirements from Danfoss. However, the adaptation of the approach by Perkins et al. [15] could be considered as part of our future work.

2.1.3 Source-to-source compilation

Code translation is a broad concept that includes different techniques for different pur-poses. In the previous section, the concept of a compiler was introduced, mainly with a task of compiling the input code into lower-level code. In these contexts, there exists another prominent concept called source-to-source compilation or transpilation. In con-trast to the standard compiler approach, a transpiler translates the input source code into a target programming language of the same level. A survey in the form of a System-atic Literature Review by Bastidas and Pérez [10] presents multiple related works where source-to-source compilers have been used for various projects and applications. Out of the 170 papers that were analyzed, 110 papers used C/C++ as the programming language, making it the most common language in the area. The conclusion was that transpilers are most commonly used for parallel compilation, compilation optimizations, code genera-tion, GPU compilagenera-tion, and embedded systems. Hasu and Flatt [16] introduce a way of applying the transpilation model based on a programming language extension of Racket, called Magnolisp. The purpose of this approach is to translate the source code of a core language into C++. Norilo [17] examined a selection of musical programming languages, with the main focus of seeking compatibility for the concept of digital signal processing. The process of programming signal processors in general-purpose low-level programming languages like C is complex as it lacks vital building blocks, making it insufficient for such purposes. It turned out that the process could be simplified with the usage of source-to-source compilers. Common Lisp Music is a musical programming language designed to program signal processors in the higher-level language Lisp. With the help of a tran-spiler, Lisp code is translated into the signal processing-compatible language C. Chaber

(13)

and Ławry´nczuk [18, 19] describe their approach of implementing a universal source-to-source compiler for automatic code generation for microcontroller-based embedded sys-tems. Microcontrollers rely on software control algorithms that are particularly developed for specific hardware platforms. Thus small changes in these algorithms require further manual modifications of the code. Utilization of a source-to-source compiler proved to be effective as it translated the algorithms written in the high-level language MATLAB into the lower-level programming language C. Interestingly enough, the work of Chaber and Ławry´nczuk additionally provides a figure describing the used source-to-source compiler process, including some steps that could be of interest for our work. The input stream of MATLAB code is gradually reviewed by the transpiler; it searches for keywords, and acts differently depending on which keyword it reads. Hence, this example demonstrates a source-to-source compiler that produces target code under certain conditions, therefore, a similar concept could be considered in our project. The work of Metere et al. [20] discusses that transpilation can even be used at the binary code level. For instance, the au-thors implemented a source-to-source compiler that translates binary programs based on the ARM microcontroller architecture ARMv8 into a target intermediate language. How-ever, this approach is too low-level, making it outside of the scope of this work. Power and Malloy [21] describe an implementation of a transpiler that translates source code from general-purpose programming languages into the XML format, which could be seen as an opposite approach compared to our project. It is based on the widely used parser generator GNU bison, which they modified to achieve the desired target XML output for their implementation. This technique, like many others, follows the standard compiler approach including data tokenization and abstract syntax tree construction.

The review conducted above proves that source-to-source compilers can be used in a wide range of applications. Although the usage areas differ a lot, the concept is similar. However, most of the examples above assume that all of the data in the input files should be translated because the input files represent programs that are expected to be valid ac-cording to certain lexical and syntactical rules. In this project, the provided input XML files do not represent the corresponding target code; these input files can be thought of as a source containing valuable data that should be extracted under certain conditions. Thus, the declarative data from the XML files act as building blocks for the imperative target code. This distinction implies a less constrained, but instead a more flexible approach, i.e., a parser that can operate freely, check conditions, and extract data in certain con-texts. The intention is therefore to apply a DOM-based XML parser [14] that enables the aforementioned requirements.

2.2 Design and implementation process

The requirement analysis based on functional and non-functional requirements [22] from Danfoss will be considered to develop and customize a compiler that is best suitable for the given XML structure. This step will include a careful analysis of the input data and conclusions of what output data should be produced by different input parameters.

The design and development process will be based on the Agile model [23,24], which implies having regular contact with the external supervisor at Danfoss. Repeated short meetings will be held to monitor the progress and discuss potential changes and improve-ments of the software developed. Therefore, the workflow will be to start with a basic initial prototype and then continuously and gradually increase the complexity to achieve a resulting compiler that addresses the requirements. The verification and validation methodology will be applied through repeated tests to confirm the expected behaviour.

(14)

2.3 Validation process

The resulting implementation will be tested against real-world XML data provided by Danfoss. Various input files will be applied in order to test different outcomes. To validate the implementation, comparisons between the produced and the expected C source code will be held. In the final phase, the prototype will be demonstrated to Danfoss. It will be reviewed by the external supervisor by receiving feedback and confirmations of the resulting functionality. Finally, different performance tests with various input files of varying size will be performed in order to test the memory and time consumption of the implementation.

2.4 Reliability and validity

In terms of reliability, the project will rely on the data provided by Danfoss, both for input XML files as well as the XSD schema. The implementation does not imply any probabilistic methods since it does not rely on random values as a part of any imple-mented calculations. Therefore, the results of the work are expected to be repeatable, with the assumption that the testing environment conforms to the used hardware and soft-ware configurations, as discussed in Section 4.1.

From the validation point of view, Danfoss are the only party that possesses the knowl-edge and opinions of the correct functionality of the expected final result. Danfoss are the main experts regarding the PLUS+1 GUIDE software [1], and also the ones providing the functional and non-functional requirements for the work. The final feedback from them will therefore be of critical value for this matter.

2.5 Ethical considerations

The project will not include any components or activities of ethical consideration, as it is not planned to conduct any experiments with humans or collect any personal data. Except for the author, only the supervisor at the Linnaeus University and the external supervisor at Danfoss will be involved in this work.

(15)

3 Implementation

In this chapter, the focus is to describe all the necessary parts needed to get an under-standing of how the software was implemented. Initially, real-world XML data provided by Danfoss will be introduced by analyzing its content and in detail describe which data should be extracted during the future parsing process. With this knowledge, an overview of the implementation will then be presented by explaining the different tasks of the trans-lation process to a deeper extent.

3.1 Input data analysis

Figure 3.1: Example of CAN XML input file.

The electronic data sheet in XML describes CAN bus nodes in the system. As seen in Figure 3.1, line 4, there exists an element called <Node>, which also has a name attribute

(16)

with the value “SensorA”. The XML file could include several <Node> elements, repre-senting different nodes in the system. However, the implementation should only generate code for a specific node, meaning that the user has to type the name of that node as an input to the program. In this case, SensorA is the one and only node, making the user forced to generate code for that particular node. The core part of the XML file is the message elements <Msg>, which include information of what messages the node will receive and transmit. A <Msg> element could either contain the attribute TxNode and/or the RxNode element. For each <Msg> element, two corresponding C source code meth-ods should be created. If the message contains the TxNode attribute, two methmeth-ods called InitCanTx_<MsgName>and ProcessCanTx_<MsgName> are generated. If the message contains the RxNode element, two methods called InitCanRx_<MsgName> and Process-CanRx_<MsgName> are generated. In the subsections below, the XML input will be analyzed by explaining the logic of what data should be extracted depending on whether the <Msg> contains TxNode or RxNode. Note that the functional requirements from the external supervisor at Danfoss determine what data should be extracted.

3.1.1 Transmitting node (TxNode)

The term Tx stands for “Transmit”. A <Msg> element containing the attribute TxNode describes a message for a particular transmitting node in the system. Looking at the second <Msg> element in Figure 3.1, line 28, it could be seen that the element contains an attribute declared as follows: TxNode="SensorA". This means that the node SensorA can transmit this message. Therefore, the C source code transmitting methods based on this message must be generated.

Looking into the contents of this message, there are four different subelements called <Signal>. The two signals XplorerCanId and XplorerCanExt will be ignored during the extraction process, as they do not contain necessary information. Therefore, the mes-sage will include two signals: speed and pressure. The following paragraphs below will describe what data should be extracted from the message and its <Signal> children.

InitCanTx method

For each message containing the TxNode attribute with the value equal to the name of the input node, this C source code method has to be generated. Every CAN message to be sent is handled by a data structure in the C code, and it is registered in the CAN driver at program startup. In the InitCanTx method, the data structure of the CAN message to be sent is initialized with the values extracted from the XML file. The list below describes which values should be extracted during the generation process for this method.

• Message name

Extracted from the Name attribute in the <Msg> element.

• ext

Extracted from the Id attribute (32-bit) in the <Msg> element. If bit 31 is 1, then extwill be 1 (extended mode). If bit 31 is 0, then ext will be 0 (standard mode).

• id

Extracted from the Id attribute in the <Msg> element. If ext is 1, then id will be 29 bits (0–28). If ext is 0, then id will be 11 bits (0–10).

(17)

• dlc

Extracted from the Length attribute in the <Msg> element.

ProcessCanTx method

For each message containing the TxNode attribute with the value equal to the name of the input node, this C source code method has to be generated. When the application needs to send a CAN message, the message’s ProcessCanTx method is invoked. It writes the signals from the application to be sent to the CAN message buffer. The list below describes which values should be extracted during the generation process for this method.

• Message name

Extracted from the Name attribute in the <Msg> element. • Signal name

Extracted from the Name attribute in the <Signal> element.

• Start

Extracted from the Start attribute in the <Decode> element. • Length

Extracted from the Length attribute in the <Decode> element. • Endianness

Extracted from the Endian attribute in the <Decode> element. • Sign

Extracted from the Sign attribute in the <Decode> element.

• Scale

Extracted from the Factor attribute in the <Scale> element. • Offset

Extracted from the Offset attribute in the <Scale> element.

3.1.2 Receiving node (RxNode)

The term Rx stands for “Receive”. Unlike the attribute TxNode, RxNode is instead de-clared as an element <RxNode>. For that reason, the placement of the <RxNode> el-ements differ. The attribute TxNode is placed directly in the <Msg> element, whereas <RxNode>elements are placed in each <Signal> element within the message. This is because a node might not require to receive exactly all of the signals in the message. If a <Msg> element contains signals which further contain a nested element <RxNode>, such a <Msg> element describes a message for a particular receiving node in the sys-tem. Looking at the first <Msg> element in Figure 3.1, line 5, it could be seen that it contains signals with elements declared as follows: RxNode="SensorA". This means that the node SensorA can receive this message, but only the signals that have the element RxNode="SensorA". Therefore, C source code receiving methods based on this message must be generated.

Looking into the contents of this message, there are four different subelements called <Signal>. The two signals XplorerCanId and XplorerCanExt will be ignored during the extraction, as they do not contain necessary information. Therefore, the message will include two signals: mode and period_ms.

(18)

InitCanRx method

For each message containing signals with nested RxNode elements with the value equal to the name of the input node, this C source code method must be generated. Every CAN message to be received is handled by a data structure in the C code, and is registered in the CAN driver at program startup. In the InitCanRx method, the data structure of the CAN message to be received is initialized with the values extracted from the XML file. The list below describes which values should be extracted during the generation process for this method.

• Message name

• ext

Extracted from the Id attribute (32-bit) in the <Msg> element. If bit 31 is 1, then extwill be 1 (extended mode). If bit 31 is 0, then ext will be 0 (standard mode).

• idfilter

Extracted from the Id attribute in the <Msg> element. If ext is 1, then id will be 29 bits (0–28). If ext is 0, then id will be 11 bits (0–10).

ProcessCanRx method

For each message containing signals with nested RxNode elements with the value equal to the name of the input node, this C source code method must be generated. When the appli-cation needs to receive a CAN message, the message’s ProcessCanRx method is invoked. It writes the signals from the CAN message buffer to be received to the application. The list below describes which values should be extracted during the generation process for this method.

• Message name

• Signal name

Extracted from the Name attribute in the <Signal> element.

• Start

Extracted from the Start attribute in the <Decode> element.

• Length

Extracted from the Length attribute in the <Decode> element.

• Endianness

Extracted from the Endian attribute in the <Decode> element.

• Sign

Extracted from the Sign attribute in the <Decode> element.

• Scale

Extracted from the Factor attribute in the <Scale> element.

• Offset

(19)

3.2 Compiler implementation overview

During the software development process, Danfoss is alternating between three different programming languages: C#, C++, and Delphi. To stay consistent, one of the external re-quirements for our project was to implement the code translator using either of those lan-guages. Therefore, the implementation was carried out using Microsoft’s object-oriented programming language C# [12], which is a part of the .NET-platform.

Read XML ﬁle and node name input

Validate XML against XSD

Parse <Msg> elements into a list

Loop <Msg> elements

create InitCanTx()

Create C ﬁle and paste generated code

Loop ends Does message contain TxNode? create InitCanRx() create ProcessCanRx() Yes No Start create ProcessCanTx() Does message contain RxNode? Yes No

Figure 3.2: The code translation process.

Figure 3.2 demonstrates how the program was constructed. Initially, the function receives two input parameters: an XML file containing all the information of the CAN

(20)

Figure 3.3: Overview of the XML Schema provided by Danfoss, describing the structure of the XML files to be processed.

messages, and a node name specifying which node to generate C source code for. The XSD file defines the structure and rules for the XML file. This is significant for validating that the content of the XML file follows the allowed syntax by not including elements and/or attributes that were not declared in the XSD file. Anything in the XML file that diverges from the XSD file results in a termination of the process, as it otherwise could result in compiling errors during the future parsing process.

Assuming that the validation successfully went through without any detected errors, the parsing process can begin. The XML file is constructed to contain multiple CAN mes-sages (denoted <Msg>), each of which has valuable information. By using the parsing technology, all these elements can be parsed and collected into a list that will be operated on in the next step of the program.

As mentioned earlier, the <Msg> elements contain the core information necessary for the generation of the C source code file. Using a loop, the content can be extracted for each message separately and at the same time be applied to the buffer that contains the compiled generated code. Lastly, the buffer containing the C source code is completed, and the only remaining step is to create a C file and paste the contents of the buffer into it.

(21)

The following sections will describe the different steps of the implementation in fur-ther detail.

3.3 XML validation

While processing XML files, Danfoss is using an XML Schema Definition (XSD) [13], see Figure 3.3 for its simplified overview. The usage of XSD files comes with several benefits as it allows defining a valid structure of an XML file. With a given XSD file, programs can expect a specific pattern that only allows predefined elements and attributes, as seen in Figure 3.4, for instance. The XSD file provided by Danfoss has therefore played an important role, as it has been utilized for the initial step of the program, namely, XML validation.

The XML validation method takes the XML and XSD file as input and validates the XML file against the XSD file. This is done by traversing the tree and comparing the different nodes to the rules defined in the XSD file. The figures below explain different outcomes depending on whether the XML file possesses the correct and required content.

Figure 3.4: The defined rules for the <Msg> element in the XSD file.

By examining the <Msg> element in Figure 3.5, it can be seen that the element con-tains the three attributes: Name, Id, and Length. The rules of the XSD file in Figure 3.4 insist that the <Msg> element can possess the following five attributes: Name, Id, Mask, Lengthand TxNode. Thus, the XML file could successfully validate against the XSD file. Another example of an XML file could be seen in Figure 3.6. In this case, the <Msg> element only contains the two attributes: Id and Length. So far, so good, as it contains the valid attributes defined in the XSD file. However, the XSD file does not entirely agree that it is flawless. A rule in the XSD file says that the Name attribute is required, and no Nameattribute can be spotted in the XML file. This means that the <Msg> element must always include Name as an attribute, otherwise, the validation will fail.

In those cases when the validation went successfully through, our implementation can proceed to the next step of the process with the XML document.

(22)

Figure 3.5: A valid <Msg> element in the XML file.

Figure 3.6: An invalid <Msg> element in the XML file.

3.4 XML parsing

In the previous literature review sections, it was concluded that an existing XML parser library [14] would be the best fit for the given problem. C# offers various alternatives in this area where the most common libraries are: XmlDocument, XmlReader, and XPath-Document. All of them have pros and cons that make them suitable for applications of

(23)

different purposes. The XmlDocument library offers a user-friendly DOM interface which makes it easy to use, with its drawback that it loads the whole XML file into the memory. The XmlReader library is quite the opposite, as it gradually processes each node from top to bottom in a non-cacheable “pull parser” way, thus making it more suitable for larger XML files where memory is a concern. The XPathDocument library is more or less a light-weight version of XmlDocument that does not contain as many features and focuses on the navigation and queries with the XPath data model [25]. Since the provided XML files are so small, the read and cached data will not imply memory consumption of larger quantities. Additionally, the parser has to check if a CAN message contains a TxNode or RxNodewith the correct node name before deciding if the methods should be generated. With the library XmlReader, this would complicate the process, as it lacks the ability to go backwards. Hence, the XmlDocument library was chosen.

The XML parsing process is the most complex task of the implementation. During this process, all of the messages will be deeply examined one at a time, and depending on the content, different C source code methods will be produced. The implementation of this task will be described below. Note that as an example, the name of the node to produce code for will be SensorA.

As seen in Figure 3.2, all of the <Msg> elements are extracted and put into a list. Since those elements are the only ones of significance, all other data outside of the <Msg> ele-ments will be ignored. The program will now work through the very first message in the XML file. It first checks if the <Msg> element directly contains an attribute called TxN-ode. Assuming that it does, it will then check if the value (node name) of TxNode is equal to the node name that the user entered as input to the program, namely SensorA. If the names are identical, it is allowed to produce the two corresponding transmitting methods: InitCanTx_<MsgName>and ProcessCanTx_<MsgName>. In this process, there will be a lot of string concatenations as new code will be continuously appended. Therefore, all of the generated methods are stored in an own StringBuilder, which is in the end merged with the common StringBuilder that contains the generated code for the whole C file.

The program has now generated methods for a CAN message to be transmitted. The parser will now continue by examining if the same CAN message consists of signals with nested <RxNode> elements. As previously mentioned in Section 3.1, each <Msg> element contains the two insignificant <Signal> elements: XplorerCanId and Xplor-erCanExt. These signals can cause problems, as they often tend to include the <RxNode> elements the parser is looking for. Therefore, if their name attributes further conforms to the node name entered as input, the parser may create the two methods unintentionally. To prevent this issue, these signals will be filtered out and removed for each CAN mes-sage. Assuming that any of the significant signals left contains the element <RxNode>, our implementation will then check if its node name is equal to the node name that the user entered as input to the program, namely SensorA. If the names are identical, it is allowed to produce the two corresponding receiving methods: InitCanRx_<MsgName> and ProcessCanRx_<MsgName>. The same logic of code generation will apply until all of the CAN messages have been processed.

3.5 Generation of C source code

The generation of C source code is the last step of the program. It includes the task of finalizing the produced buffer by taking its content and pasting it into a newly created C file. The final result will then be a C source code file containing the generated methods that correspond to the CAN messages defined in the XML file.

(24)

4 Results

Based on the implementation in the previous chapter, the results for our solution will be presented here by providing different examples of input data in XML and the correspond-ing generated output data in C source code. Lastly, a performance evaluation in the form of memory consumption and total runtime duration will be presented.

4.1 Testing environment

Table 4.1 describes the hardware and software used when the implementation was tested. The same set of components were also used during the development process.

Table 4.1: Testing environment configuration Hardware/software component Description

CPU Intel Core i7-2600 @ 3.4 GHz

RAM 16 GB

OS Windows 10 64-bit

C# compiler Visual Studio Code 1.45.0 System Namespace .NET Core 3.1

System.IO Namespace .NET Core 3.1 System.Text Namespace .NET Core 3.1 System.Xml Namespace .NET Core 3.1 System.Xml.Schema Namespace .NET Core 3.1 System.Collections.Generic Namespace .NET Core 3.1 System.Linq Namespace .NET Core 3.1

4.2 Demonstration of the solution

In this subsection, our solution will be demonstrated with input files that include (1) trans-mitting nodes, (2) receiving nodes, and (3) combined receiving + transtrans-mitting nodes.

(25)

4.2.1 Example of a transmitting node

Figure 4.1: XML input file example containing TxNode.

(26)

4.2.2 Example of a receiving node

Figure 4.3: XML input file example containing RxNode.

(27)

4.2.3 Example of a combined receiving and transmitting node

(28)

Figure 4.6: C source code output file generated from the XML in Figure 4.5.

4.3 Performance evaluation

To evaluate the performance of our compiler implementation, it was launched from an ex-ternal shell script for each of 50 test runs. Thus, the results below reflect the memory and time necessary to initialize the software, load and parse input data, and finally, produce the resulting C source code as the output. The memory consumption was measured with the Process.WorkingSet64 property in the namespace System.Diagnostics. It returns the amount of physical memory the process has allocated in RAM.

(29)

73,3 72,18 76,2 85,24 Time (ms) 0 25 50 75 100

1 message 5 messages 10 messages 20 messages

Average of 50 runs

Time consumption

Figure 4.7: Bar chart of the average time consumption for each input file. The error bars represent the standard deviation.

22,04 22,17 22,31 22,69 Memory (MB) 20 21 22 23

1 message 5 messages 10 messages 20 messages

Average of 50 runs

Memory consumption

Figure 4.8: Bar chart of the average memory consumption for each input file. The error bars represent the standard deviation.

(30)

5 Analysis

This chapter provides an analysis and discussion of the performance evaluation results presented in the previous chapter. The analysis is followed by a section of domain expert feedback from the external supervisor.

5.1 Analysis of the performance evaluation results

The performance evaluation of the resulting implementation was carried out with four experiments, i.e., XML input files with different numbers of CAN messages to be pro-cessed by the program. Figure 4.7 shows that regardless of how many messages the transpiler processes, the time consumption will always have a minimum of approximately 70 milliseconds. The difference in time consumption of 1 message, 5 messages, and 10 messages are so small that one could almost perceive that randomness—caused by the external factors such as the OS kernel and other running software processes—determines which one takes the longest time. At the earliest of 20 messages, a clear increase could be comprehended. Usually, input files will not get bigger than this, according to the domain experts from Danfoss. Therefore, there is no need in evaluating even bigger files. It could also be seen that it does not contain any apparent outliers, which is gratifying in terms of reliability; thus, the user can always expect a consistent elapsed time.

When it comes to memory consumption as Figure 4.8 describes, very small increases can be noted as the files get larger. In fact, the differences are so tiny that they do not reach even one megabyte between the cases with the smallest and the largest file. A conclusion can be made that regardless of how many messages are included, they will have a very small impact on the memory consumption of the program. As for the bar chart of memory consumption, no outliers are visible, which disregards the signs of memory leaks for these executions.

5.2 Domain expert feedback

The resulting solution was presented to Danfoss by sending the project folder to the ex-ternal supervisor. This included all of the material that was used during the development of the program. To validate the implementation, the external supervisor explored the pro-gram by testing its functionality, and this process was documented as described below.

1. The project was opened in Visual Studio 2019.

2. The output file path was modified in the C# source code.

3. The input file was SensorA_Little.xml, describing the CAN messages for a demo sensor implementation, SensorA.

4. The program was executed with the debugger.

5. The generated C source code file was reviewed and everything looked OK. It con-tained one function to handle one incoming CAN message with settings for the sensor, and one function to handle outgoing CAN message with sensor values.

6. The file was copied to a PLUS+1 GUIDE [1] project folder and added to the project.

7. The graphical code is calling the generated receive function, processing the incom-ing signals, and then callincom-ing the generated transmit function.

(31)

8. The application was compiled within the PLUS+1 GUIDE [1] tool and loaded to a sensor controller hardware using the PLUS+1 Service Tool.

9. Using a CAN monitoring tool called CAN King, a settings message was sent to the sensor controller.

10. The sensor controller was responding by sending the defined sensor values on the CAN bus.

11. PLUS+1 Service Tool was connected to the sensor controller, and this verified that the incoming settings values were extracted from the incoming CAN message cor-rectly.

Apart from only testing the solution, a source code review of the developed C# source code was carried out. According to the external supervisor, the impression is that the code is well written, well structured, well documented, and easy to follow. However, a suggestion was to decompose the main function into one or more functions, to improve the readability of the code even more. This suggestion will be considered as part of our future work.

(32)

6 Discussion

The goal of this work was to implement a program that could translate CAN messages described in an electronic specification in the XML format into the equivalent code in the programming language C. This model was intended to facilitate code generation by re-placing the manual approach that has been traditionally used by the external stakeholders at Danfoss. Based on the results presented in Section 4.3 and validation from the domain expert discussed in Section 5.2, we can conclude that the problem has been answered suc-cessfully. What used to be time consuming and error-prone can now be accomplished in a fraction of a second with equivalent results. The problem and results can not be directly compared with other related works, as it is a domain-specific specialized solution. On the other hand, the same does not apply to the implementation, as the source-to-source compiler construction projects can share some similarities. Most of the related works discussed in Section 2.1 used a more standard compiler construction approach with lex-ical and syntactlex-ical analyses, syntax trees, intermediate representations, etc. This work followed another approach using a more general XML parser library [14], which was con-sidered to suit the given problem sufficiently well. With that being said, implementing an alternative solution based on parser generation tools such as ANTLR [9] or direct compila-tion of XML Schema grammars [15] would most likely achieve similar results, but would be subject to external non-functional requirements for the development technologies as well as the necessity to re-implement support for a range of XML format features.

Another aspect to be mentioned is that this implementation is just a prototype at this point, produced as a proof of concept for investigating the benefits of automating the data processing tasks. The transpiler is still not deployed into production mode, making it difficult to foresee undetected and underlying bugs. Further development of this solution is part of our work, as discussed in the next chapter of this report.

(33)

7 Conclusion

We can now summarize the outcomes of this thesis project according to the objectives outlined in Table 1.1.

O1 Conduct literature review of existing compiler construction approaches

In Chapter 2, we performed a review of the most common compiler construction ap-proaches. Firstly, the standard compiler construction approach was explained, i.e., lexical and syntactical analyses, symbol tables, semantic analysis, intermediate representations, optimization passes, and code generation. Furthermore, the parser generator tool ANTLR was described, and we discussed how it could be applied in the generation of an XML parser. Lastly, we explored the usage areas of source-to-source compilers by providing examples of related works based on this concept. Thus, objective O1 has been achieved.

O2 Implement the compiler

The implementation process described in Chapter 3 is motivated by an analysis of the XML files provided by Danfoss. This included a clarification of the structure of the XML files, as well as an explanation of what data should be extracted from the CAN messages during the parsing process, according to the functional requirements from Danfoss. In the next section, we described the development of our software solution based on an existing XML parser library. The solution acts like a transpiler: it reads the electronic specification in XML as input and generates a file with the corresponding C source code. Therefore, objective O2 has been accomplished.

O3 Run test cases with different input data to test the compiler

The results of the developed solution are presented in Chapter 4. Various input files were applied to test different outcomes and confirm the expected behaviour. To validate the functionality from an objective perspective, domain experts at Danfoss examined the program externally with the PLUS+1 GUIDE software. The received feedback described in Chapter 5 confirmed that the application extracted the XML data and generated the C source code correctly, thus helping us attain objective O3.

O4 Evaluate memory and time consumption

A performance evaluation was conducted in the form of measurements of the memory and time consumption of the resulting solution. The bar charts in Chapter 4 present four different experiments with inputs of varying size. Each experiment was launched for each of 50 test runs, and the mean values for the allocated memory and the elapsed time were calculated. The values reflect a stable—based on the testing environment configurations in Table 4.1—application with no visible outliers. The total runtime varied between 73–85 milliseconds with a memory consumption of approximately 22 megabytes. This implies that objective O4 has been completed.

7.1 Future work

There are some aspects of our project implementation that could be developed further to improve the application. For instance, the path to the input file and the node name to

(34)

generate code for are currently hard-coded into the beginning of the source code of the program. In production, this is obviously not a recommended approach. Furthermore, the application could either be designed as a Windows Application, where the user can browse in the library and select the XML input file, and type in the node name in a text field; or as a Console Application, where the user types the two inputs as an argument before executing it in the terminal. More realistically, the developed application and its generated C file are meant to be integrated with the PLUS+1 GUIDE software [1], and thus become a part of it.

As mentioned before, the work of generating efficient parsers through direct compi-lation of XML Schema grammars by Perkins et al. [15] could be further investigated and potentially become a contribution to increase the performance of the XML parser. Alter-natively, the currently used DOM-based XML parsing approach could be replaced with another standard XML parsing model [14] if the size and complexity of the input files eventually require a solution of much higher performance.

In terms of functionality, the application has the potential to scale even better. For this work, the requirement was to generate code for a single and desired node in the XML specification. Usually, this file contains additional nodes that can appear anywhere. Fur-ther development could Fur-therefore include the objective of generating separate C source code files for all of those nodes in the same execution. Additionally, the functional requirements—provided by Danfoss—for this thesis project allowed to skip extraction for some data within the <Signal> elements. As seen in the XML Schema overview in Figure 3.3, there exist other data like Range and Traffic, for instance. Future work could include the possibility of utilizing those values as well, and hence extend the functional-ities of the generated C source code. Finally, further evaluation with a variety of input XML files could be conducted as part of future work.

(35)

References

[1] Danfoss A/G, “PLUS+1 GUIDE,” 2004, last accessed on April 22, 2020. [Online]. Available: https://danfoss.com/en/products/software/dps/plus1-software/ plus1-guide/

[2] N. Liang and D. Popovic, “The CAN bus,” in Intelligent Vehicle Technologies, ser. Automotive Engineering Series, L. Vlacic, M. Parent, and F. Harashima, Eds. Ox-ford, England, UK: Butterworth-Heinemann, 2001, pp. 21–64.

[3] ISO/TC 22/SC 31, “Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling,” International Standard Organization, ISO 11898-1:2015, 2015, last accessed on April 22, 2020. [Online]. Available: https://iso.org/standard/63648.html

[4] B. DuCharme, XML: The Annotated Specification. Upper Saddle River, NJ, USA: Prentice-Hall PTR, 1998.

[5] A. V. Aho, M. S. Lam, R. Sethi, and J. D. Ullman, Compilers: Principles, Tech-niques and Tools, 2nd ed. Boston, MA, USA: Addison-Wesley, 2006.

[6] D. Grune, K. Van Reeuwijk, H. E. Bal, C. J. Jacobs, and K. Langendoen, Modern Compiler Design, 2nd ed. New York, NY, USA: Springer-Verlag, 2012.

[7] J. Stanier and D. Watson, “Intermediate representations in imperative compilers: A survey,” ACM Computing Surveys, vol. 45, no. 3, Jul. 2013.

[8] T. Parr, Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages. Raleigh, NC, USA: Pragmatic Bookshelf, 2009.

[9] T. Parr, The Definitive ANTLR 4 Reference, 2nd ed. Raleigh, NC, USA: Pragmatic Bookshelf, 2013.

[10] F. A. Bastidas and M. Pérez, “A systematic review on transpiler usage for transaction-oriented applications,” in Proceedings of the IEEE Third Ecuador Tech-nical Chapters Meeting, ser. ETCM ’18. IEEE, 2018.

[11] B. W. Kernighan and D. Ritchie, The C Programming Language, 2nd ed. Upper Saddle River, NJ, USA: Prentice-Hall PTR, 1988.

[12] A. Hejlsberg, M. Torgersen, S. Wiltamuth, and P. Golde, C# Programming Lan-guage, 4th ed. Boston, MA, USA: Addison-Wesley Professional, 2010.

[13] J. Roy and A. Ramanujan, “XML schema language: Taking XML to the next level,” IT Professional, vol. 3, no. 2, pp. 37–40, Mar.–Apr. 2001.

[14] T. C. Lam, J. J. Ding, and J.-C. Liu, “XML document parsing: Operational and performance characteristics,” Computer, vol. 41, no. 9, pp. 30–37, Sep. 2008.

[15] E. Perkins, M. Matsa, M. G. Kostoulas, A. Heifets, and N. Mendelsohn, “Generation of efficient parsers through direct compilation of XML Schema grammars,” IBM Systems Journal, vol. 45, no. 2, pp. 225–244, 2006.

(36)

[16] T. Hasu and M. Flatt, “Source-to-source compilation via submodules,” in Pro-ceedings of the 9th European Lisp Symposium on European Lisp Symposium, ser. ELS ’16. European Lisp Scientific Activities Association, 2016.

[17] V. Norilo, “Kronos: A declarative metaprogramming language for digital signal pro-cessing,” Computer Music Journal, vol. 39, no. 4, pp. 30–48, 2015.

[18] P. Chaber and M. Ławry´nczuk, “Auto-generation of advanced control algorithms’ code for microcontrollers using transcompiler,” in Proceedings of the 21st Inter-national Conference on Methods and Models in Automation and Robotics, ser. MMAR ’16. IEEE, 2016, pp. 454–459.

[19] P. Chaber and M. Ławry´nczuk, “AutoMATiC: Code generation of model predictive control algorithms for microcontrollers,” IEEE Transactions on Industrial Informat-ics, vol. 16, no. 7, pp. 4547–4556, Jul. 2020.

[20] R. Metere, A. Lindner, and R. Guanciale, “Sound transpilation from binary to machine-independent code,” in Formal Methods: Foundations and Applications, ser. LNCS, S. Cavalheiro and J. Fiadeiro, Eds., vol. 10623. Cham, Switzerland: Springer International Publishing, 2017, pp. 197–214.

[21] J. F. Power and B. A. Malloy, “Program annotation in XML: A parse-tree based ap-proach,” in Proceedings of the Ninth Working Conference on Reverse Engineering, ser. WCRE ’02. IEEE, 2002, pp. 190–198.

[22] K. Wiegers and J. Beatty, Software Requirements, 3rd ed. Redmond, WA, USA: Microsoft Press, 2013.

[23] J. Highsmith and A. Cockburn, “Agile software development: The business of inno-vation,” Computer, vol. 34, no. 9, pp. 120–127, Sep. 2001.

[24] F. Paetsch, A. Eberlein, and F. Maurer, “Requirements engineering and agile soft-ware development,” in Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, ser. WET ICE ’03. IEEE, 2003, pp. 308–313.

[25] J. Clark and S. DeRose, “XML path language (XPath) version 1.0,” W3C, W3C Recommendation REC-xpath-19991116, Nov. 1999, last accessed on April 22, 2020. [Online]. Available: https://www.w3.org/TR/1999/REC-xpath-19991116/

Translation of CAN Bus XML Messages to C Source Code

Author:

Gustav Andersson

Supervisor:

Dr. Kostiantyn Kucher

External Supervisor:

Fredrik Björn

Semester:

Spring 2020

Subject:

Computer Engineering

Engineering Degree Project

Translation of CAN Bus XML

Messages to C Source Code

Abstract

Preface

Contents

1

Introduction

2

Method

3

Implementation

4

Results

5

Analysis

6

Discussion

7

Conclusion

References