DEV Community: Aravind B N

Understanding J1939 SAE Protocol: The Complete Guide to Communication in Commercial Vehicles part-5.

Aravind B N — Tue, 05 Mar 2024 04:09:01 +0000

Hello Readers, 👋😃
My name is Aravind B. N., and I work at Luxoft India as a junior software developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to discuss the important processes involved in learning the SAE J1939 communication protocol Part-4 This is part 5 of the SAE J1939 communication protocol. Here we will discuss the Solution and Configurations and Handling in a Dynamic Network.

Cont... [Part-4]
Solution & Configurations
Priority

2.Program-configurable
The device at first broadcasts the PGN ‘Address Claimed’ with NULL address (254). This is seen on the network as ‘Cannot Claim Address’. An ECU can be assigned to a new device address by using “Commanded Address” network management service. The latter can be achieved through an external tool or any intelligent object in the network, "Cannot Claim Address"

The figure represents a sample scenario involving two Electronic Control Units (ECUs) known as ECU A and ECU B, undergoing initialization and address claiming on a network with particular focus on conflict resolution when both ECUs try to claim the same address.

A step-by-step explanation of what happens in the diagram is given below:

Initialization: Both ECU A and ECU B begin their initialization process as indicated by dashed lines at top of each vertical line. This is when each of them performs self-checks and gets ready for network communication.

Address Claimed by Both ECUs: NAME A claims an address over the network using Source Address (SA) of 20. At almost the exact same time, NAME B assigns itself this identical address (SA = 20), culminating into conflicts because two devices are trying to use similar source address.

Name comparison: The address contention is resolved by name comparison. Each ECU undertakes a NAME identifier check to know which one among them should have the highest priority when it comes to addressing.

ECU A Reclaims Address: After performing the name comparison, ECU A takes over the address SA = 20 with NAME A probably because of a higher priority as per the name comparison.

ECU B Cannot Claim Address: Having lost in the name comparison, ECU B tries to claim an address but this is not possible. It goes for SA = 254 and NAME B by default; which means that it could not acquire the desired address and now needs to be assigned new one.

Random delay and Commanded Address: Delayed Randomly and Commanded Address: After failing to claim an address, ECU B delays for some random period. This helps in avoiding repeated immediate conflicts and also gives time for network management system to resolve such issues. The footnote at the end indicates that if supported by the ECU, an optional “Commanded Address” network management service can be applied to give a new address for ECU B. This way, it would intervene in this case so that there will be no other conflict during communication process between all these ECUs.

Continued Operation: According to the diagram, after address claiming and conflict resolution processes, ECU A will remain operational with static address = 20, whereas network management intervention will eventually assign ECU B a new address.

The vertical lines have been used to represent the two ECUs while the horizontal lines show the events that occur over time (t) for each ECU. This process ensures that every ECU on the network is assigned a unique address; an essential requirement in any communication system or networked device.

3.Manually configurable
To assign a new address to this type of ECU, only a switch may be employed. The most common method of doing this kind of configuration is installing according to location in vehicle. An I/O port from the processor decodes this number as an address. Therefore, it is possible for door ECU to determine by itself whether it is installed on right or left and then select suitable location code.

4.Non-configurable
A non-configurable type of ECU can only be given another address through reprogramming its software.

Handling in a Dynamic Network

AAC Bit
An electronic control unit (ECU) that can be versatile and is not limited to a network connection should support the setup described as "Self configurable" in the section, on Solutions and Configurations. An ECU configured in this way may be identified by a NAME with its significant bit designated as "Arbitrary Address Capable." This designation indicates that ECUs can independently search for their addresses. If an ECU exists once in the network it can opt to use a fixed device address without needing to set the "Arbitrary Address bit. ECUs that are self configurable and have this feature activated are given priority over those lacking this setting in terms of naming conventions.

Request
The J1939 network management has an important mechanism called PGN ‘Request’. In turn, any PGNs can be requested from ECUs using this PGN. Therefore, it can also refer to the “Address Claimed” PGN. Here, the ‘Address Claimed’ PGN should respond to this “Request for Address Claimed”.

Important: When requesting ECU has a valid address, it must acknowledge its request itself!

NULL Address
Usually used at the beginning of communication during dynamic networks, whereby frequently request mechanism is applied. Thus any ECU that wants to participate in communication will request for the address status before starting addressing.

Note: PGN 59904 is an exception in J1939. Specifically, this PGN is the only type of parameter group that can be sent without a valid address, but from NULL (254) instead.

Fig:Request for Address Claimed

The image you have shared with me looks like a series of interactions between an Electronic Control Unit (ECU) labeled “ECU A” and a network which is probably within the Controller Area Network (CAN) of a vehicle, or something similar to it in terms of ECU to ECU communication among other complex electronic systems found in vehicles.

This diagram can be described step by step as follows:

ECU A: This is the first processor that initiates electronic control unit to communication.
Request for Address Claimed (SA = 254): To make all devices claim their addresses, ECU A transmits out a message over the network. The broadcast address for some protocols is 254 meaning every device should listen and capable of responding.
Address Claimed (SA = X, NAME B): A computer on the network called NAME B has added its name while claiming its address with source address X.
Address Claimed (SA = Y, NAME C): Another computer named NAME C however claims its address using source address Y.
Address Claimed (SA = Z, NAME D): Another ECU, known as NAME D has confirmed its address by matching it with the source address Z.
Time-out of 1250 ms: A timeout of 1250 milliseconds is set, indicating that ECU A will wait for this duration to allow all ECUs, on the network to respond to the address claim request.
Address Claimed (SA = T, NAME A): Following the timeout period ECU A asserts its address using source address T. Introduces itself as NAME A.

The vertical lines with arrows indicate the timeline, for both ECU A and the network showing that these events occur sequentially over time.

In networks, with devices it's common for them to establish their presence and secure addresses for effective communication. This helps prevent address conflicts and ensures messages reach the ECU. Such an address claiming process is frequently seen in systems utilizing the SAE J1939 protocol or similar protocols, in heavy duty vehicle and industrial settings.

Understanding J1939 SAE Protocol: The Complete Guide to Communication in Commercial Vehicles part-4.

Aravind B N — Tue, 05 Mar 2024 04:08:44 +0000

Hello Readers, 👋😃
My name is Aravind B. N., and I work at Luxoft India as a junior software developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to discuss the important processes involved in learning the SAE J1939 communication protocol Part-3 This is part 4 of the SAE J1939 communication protocol. Here we will discuss the Network Access and Solution and Configurations.

Network Access

Network Admission
In J1939, the term network management should not be confused with that of network management in general automotive settings. In the automotive domain, network management is used to put the ECUs (Electronic Control Units) of a network into a defined “agreed upon” idle state without losing any bus information.

As, per the J1939 standard this term pertains to controlling access to communication (entry to the network) and managing device addresses, in networks. This is where properties such as device address and NAME come into play (see chapter Names and Addresses[part-2]).

Address Claiming

The simplest form of J1939 network management is when every ECU sends “Address Claimed” right after booting, before they start communicating. By using the 'Address Claimed' parameter group (PGN‎ 0x00EE00) it is possible to reveal the 'Address Claim' which includes the devices name and a standard reset device address. Mainly in static networks this is done so as to unveil the topology of a network. Therefore, an example would be diagnosing tools that will determine whether or not there is presence of retarder in vehicle.

Conflict Resolution

Similarly “Address Claim” also applies to dynamic networks. Furthermore, the network management can be used to address any address conflict that occurs here. These may occur, for instance, when an ECU is subsequently joined to a network (already in operation) and this ECU uses a predetermined address already utilized on the network. This conflict must be resolved as all addresses within the network should be unique and non-repetitive.

Fig: Address Claim Static

This figure appears like a representation of some events in a communication process between Electronic Control Unit (ECU) and Network possibly in automotive domain. ECUs are computerized controllers that handle many functions such as engine control/transmission/brake systems in vehicles. It is a simple timeline of how ECU gets initialized before communicating with the network.

Here is what each section means:

Initialization: The dotted line on the left side titled ‘Initialization’ shows where ECU A starts its start-up sequence from. This could entail self checks, software booting up and getting ready to communicate over the network.

250 ms delay: At the beginning, there is a 250-millisecond delay. This waiting sequence may be an own built-in ECU wait time before it tries to communicate on network to ensure that it is fully operational prior sending any messages or it does not conflict with others ECUs are starting up.

Address Claimed (SA = 20): After the pause, ECU A claims an address on the network. It means Source Address, and this refers to a unique identifier for an ECU on the network; in such cases, this particular ECU is claiming number 20.For successful communication through a network, all other devices must identify data sent by ECU A and accordingly deliver responses.

Standard Messages (SA = 20): Having claimed its address, standard messages start emanating from the ECU A via Its Source Address (SA = 20). They can represent any kind of information including data readings, status updates or control commands which are being handled by this specific ECU. The dotted vertical dash lines indicate that there are some messages transmitted one after another over a period of time to the network.

Network: The line, on the right labeled "Network" represents the network itself which could be a vehicles Controller Area Network (CAN) bus or any other type of communication system used for ECUs to exchange information. The arrows pointing from ECU A to the network indicate the direction of communication showing that ECU A is sending messages to the network.

The timeline at the bottom, with "t" likely signifies time illustrating the progression from the initialization phase through the communication phase.

In essence this diagram provides a high level overview of an ECU booting up obtaining a network address and then commencing its operation of transmitting messages to the network at set intervals.

Solution & Configurations

Priority
The identifier is utilized to settle disputes and to prioritize addresses. Therefore when an address conflict arises through the "Address Claim " the devices, in question must compare their identifiers. This comparison process is conducted bit by bit commencing from the Significant Bit (MSB). Following the principle as CAN arbitration a zero takes precedence over a one. The identifier with the numerical value triumphs in the conflict resolution allowing the associated ECU to utilize that address. The behavior of the ECU possessing the lower priority identifier in this scenario is contingent upon its setup. There are four setups for ECUs in this context;

1.Self-configurable
Following address loss the device autonomously seeks an address, within the range of 128 to 247 and endeavors to secure it.
The animation depicts a scenario where two Electronic Control Units (ECUs) named ECU A and ECU B are initializing and vying for addresses on a network. It also showcases a conflict resolution process, for address claiming. Here's a breakdown of the events shown in the diagram;

Fig: Address claimed Dynamic.

Initialization: Both ECU A and ECU B begin their initialization process as shown by the dashed lines at the top of each line. This is where each ECU conducts self checks and gets ready to communicate on the network.
Address Claimed by ECU A: ECU A secures an address on the network with the Source Address (SA) of 20. Is known as NAME A. This marks the step in establishing communication, on the network.
Address Claimed by ECU B: At the time ECU B also attempts to claim the same address, on the network (SA = 20) and is recognized by NAME B. This situation arises because two devices are competing to use the source address.
Name comparison: To resolve this conflict a comparison of names is carried out. Each ECU compares its NAME identifier to determine which one holds priority in claiming the address. In this scenario NAME A emerges as the higher priority choice over NAME B.
Address Reclaimed by ECU A: Following the name comparison process, ECU A successfully reclaims the address SA = 20 with its designated name, NAME A having secured priority, in the naming comparison evaluation.
ECU B Searches for a New Address: ECU B is now seeking an address after losing priority in the name comparison. It successfully secures an address SA = 128 under the name B. This enables ECU B to communicate on the network without any address conflicts.
Continued Operation: As, per the diagram following the address claiming process and conflict resolution both ECUs are seen to continue operating on the network with their addresses. ECU A maintains its usage of SA = 20 while ECU B now operates using SA = 128.

The vertical lines depict the two ECUs while the horizontal lines show the sequence of events, over time (t) for each ECU. The diagram illustrates how each ECU is assigned an address on the network for seamless communication and operation within a networked system like in automotive settings where multiple ECUs collaborate, without disruptions.

This concept will be covered more in the next article, with examples.
Do let me know if you have any queries in the comments below.

Thanks for reading.

Unit Testing: A Very Important Scheme of Software Development

Aravind B N — Mon, 26 Feb 2024 10:02:34 +0000

Hello‎‎ Readers,
My‎‎ name‎‎ is‎‎ Aravind‎‎ B‎‎ N,‎‎ and‎‎ I‎‎ work‎‎ at‎‎ "Luxoft‎‎ India"‎‎ as‎‎ a‎‎ Junior‎‎ Software‎‎ Developer.‎‎ Luxoft has provided me with chances to engage in projects sparking my interest in exploring the essential aspects of Unit Testing development and learning.

Introduction

As a software developer it's essential that the code is dependable, effective and easy to manage. One tool that cannot be missed in this fight is unit testing. Unit testing as the process of evaluating individual units or components of a software independently to check if each works as expected. This article will discuss why unit tests are important, types of automated tests, basics of unit testing and an example application overview with test scenarios. It will also talk about dealing with bugs result and feedbacks in test running with advanced topics touch on before ending up with modern significance of unit testing.

Importance of Unit Testing

In the cycle of software development, this is where unit tests play a vital role for many reasons. First off, it makes sure that every piece of code functions correctly on its own such that issues can be detected and fixed early during development process. By identifying problems at the level where they occur rather than allowing them to spread through various parts of the system, developers can reduce chances for more complex and costly bugs later on.

Moreover, it is also a kind of documentation to let the team know what should be done as they test their code. Each component’s task can be understood in terms of what it does and how to do that by using the references made when testing this piece of software for future developers who may come on board. In addition, unit tests allow for easier refactoring as a result of having safety nets; thus making alterations with confidence knowing that the full coverage by testing is well catered.

In addition, unit testing builds quality and responsibility among the development teams. Writing tests leads to modularization, reusability and loose coupling which has an impact on maintainability and scalability of software systems.

Types of Automated Tests

Automated testing is necessary to make sure that everything goes smoothly during testing and good results are attained (Knight et al., 2007). Various types of automated tests exist in order to serve specific purposes in software testing:

Unit Tests: As mentioned before, individual units such as functions or methods are tested independently with unit tests.
Integration Tests: Integration test make sure that different parts or components work together exactly as they were meant to do in a given application.
End-To-End Tests: These end-to-end tests, also called functional tests, confirm that the whole workflow of an application is operating from beginning to end with user activities and system integrations.
Rechecking Functionality; Regression tests are created to double check functionality that has already been implemented making sure that any new code modifications do not negatively impact it.
Checking Performance; Performance testing is carried out to pinpoint areas where performance may be limited by testing how well an application responds, scales and remains stable under workloads.
Initial Validation Tests; Smoke tests are used to assess if an application is stable enough, for testing quickly validating its key functions.

Each kind of automated test has a different role in guaranteeing overall quality and reliability of software applications.

Principles of Unit Testing

Several important principles guide effective unit testing:

Isolation: Unit tests should prevent the code being tested from relying on external resources like databases or network calls through mocking or stubbing techniques.
Independence: Each unit test must be independent from others so that their consequences would not influence each other’s results.
Readability: Test names must be descriptive and assertions be clear so that unit tests can be understood easily and maintained.
Speed: To this end, the speed at which they execute should allow programmers to obtain immediate feedback as they move through iterations during development.
Completeness: Unit tests need to cover different edge cases and scenarios in order to ensure robustness of the code base.

They help keep unit tests effective and reliable all through the life cycle of software development.
Example Application Overview
A simple example application for managing cars, including functionalities for creating, updating, and deleting car records will be considered. The focus will be on testing the car creation service specifically on make and model properties of car objects.
Testing the Car Creation Service
Let us start by writing unit tests for the car creation service:
1. Testing the make Property:


def test_car_make():

    car = Car(make="Toyota", model="Camry")

    assert car.make == "Toyota"

This test ensures that the make property of the car object is set correctly.

2. Testing the model Property:


def test_car_model():

    car = Car(make="Toyota", model="Camry")

    assert car.model == "Camry"

With this tester also, the model attribute of the car object is correctly assigned.

Handling Test Failures and Feedback

For sure, there could be some tests that fail due to bugs or changes in the code. Whenever a test fails, it becomes very important to investigate why it failed and fix the problem without delay. Developers should maintain a feedback loop where any failing tests are handled immediately so as to maintain validity of the test suite.

Advanced Topics and Conclusion

Test-driven development (TDD) is an advanced area of unit testing where tests are written before coding while property-based testing is another in which they are generated from properties that the code must satisfy.

It can therefore be concluded that unit testing is an essential element in modern software development. It helps to ensure reliability, functionality and maintainability of codes while fostering quality culture and responsible development teams. The principles behind unit testing along with automated testing procedures ensure developers deliver high-quality software with confidence on customer expectations.

This practice not only enhances code quality but also promotes productivity amongst developers as well as collaboration hence better outcomes for dev and end-users alike.

An In-Depth Exploration of the CAN Calibration Protocol (CCP)

Aravind B N — Mon, 19 Feb 2024 06:55:31 +0000

Hello Readers,‍‍‍‍‍‍‍‍󠁲
My name is Aravind B. N., and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, these experiences have inspired me to involved in learning of CAN Calibration Protocol

Introduction
The (CCP) CAN Calibration Protocol has become widely accepted as a standard, in the industry for calibrating controllers during module development. This detailed article aims to offer readers an understanding of CCP including its core principles, dialogue structure, command functionalities, message exchange mechanisms, implementation considerations, resource requirements, performance assessments and various applications in module development tasks. Exploring the intricacies of CCP allows developers to gain insights into its capabilities and harness its potential to enhance module performance.

CCP Essentials; Going beyond calibration CCP provides a range of general purpose features that make it a versatile tool for module development activities. From calibration tasks CCP enables real time access to Electronic Control Unit (ECU) parameters allowing adjustments to process algorithms and providing real time data retrieval, from the ECU. This adaptability empowers developers to tune and optimize module performance.

CCP Dialog: The CCP dialogue involves exchanging messages, between the calibration tool and the ECU. The Command Receive Object (CRO) is used to send commands from the tool to the ECU while the Data Transmission Object (DTO) allows the ECU to reply to the CRO. The CCP specification outlines a framework that specifies how each message is structured and what it contains ensuring communication standards, between the tool and the ECU.

CCP Commands: CCP features a variety of commands each serving purposes, in the calibration and development process. These commands facilitate tasks like adjusting ECU parameters changing calibration values starting flash programming and fetching real time measurement data. The CCP specification outlines descriptions of each command including their parameters, expected responses and functions.

CCP Communication: CCP communication relies on the Controller Area Network (CAN) bus, a used communication protocol in the industry. The CAN bus enables efficient data exchange, between the calibration tool and the ECU. Each CAN Identifier is restricted to 8 data bytes to ensure use of bandwidth. Inside the ECU the CCP Driver processes commands carries out requested operations and sends back responses via the CAN bus.

Measurement Data Acquisition: CCP offers two methods, for acquiring measurement data a polling approach and the utilization of Data Acquisition (DAQ) lists. In the polling method the calibration tool requests data and the ECU responds with the requested information. On the hand DAQ lists allow for efficient and synchronized data acquisition. These lists consist of Object Descriptor Tables (ODTs) that outline the data to be acquired and the associated event triggers or time periods. This method empowers the ECU to autonomously send measurement data to the calibration tool reducing the necessity, for polling.

Tool Considerations: When using CCP along, with tools like Vectors CANape developers can access features that improve the calibration and development process. These tools offer a to use interface for visualizing and adjusting ECU data. They enable developers to view ECU parameters in units, symbolic values or graphical formats which helps deepen their understanding of the calibration process and allows for, on the fly adjustments.

CCP Applications: CCP is utilized in aspects of module development including calibration, parameter tweaking and real time data collection. It empowers developers to fine tune ECU settings enhance process algorithms and validate module performance. CCP proves beneficial during the development and testing stages by facilitating calibration cycles and providing real time monitoring of crucial parameters.

CCP Driver Implementation: Implementing a CCP driver involves two components; the command processor and the DAQ processor. The command processor deals, with receiving CRO commands from the calibration tool and generating Command Return Messages (CRM) in response. It verifies that the requested tasks are carried out accurately and provides feedback to the calibration tool. On the hand the DAQ processor is, in charge of overseeing the acquisition and transmission of measurement data based on specified DAQ lists. Its role is to ensure synchronized and efficient data collection enabling real time monitoring and analysis.

CCP Resource Requirements: To successfully integrate a CCP driver it is essential to manage the use of resources, within the ECU. The CCP software driver requires resources like RAM, ROM and CPU time with specific needs varying based on the chosen implementation, optional features and module complexity. Evaluating and assigning the resources is vital for ensuring functionality and performance.

CCP Performance Ratings: The performance of CCP is impacted by factors such as command execution times, message transmission rates and system configuration as a whole. The efficiency of implementation, ECU hardware capabilities and CAN bus communication bandwidth all play a role, in determining the CCP drivers performance levels. Developers should take these aspects into account during design and optimization stages to meet desired performance standards.

Conclusion: the CAN Calibration Protocol (CCP) serves as a tool, in the industry for calibrating controllers and aiding module development. Its versatility, communication protocol and real time data acquisition support make it highly beneficial, for developers. By mastering the basics of CCP understanding its dialogue structure, command functions and message exchange methods developers can effectively utilize it to enhance module performance simplify calibration processes and attain outcomes in module development tasks.

This concept will be covered more in the next article, with examples.
Do let me know if you have any queries in the comments below.

Thanks for reading.

XCP - Universal Measurement and Calibration Protocol Part-2

Aravind B N — Mon, 19 Feb 2024 06:47:16 +0000

Hello‎‎ Readers,
My‎‎ name‎‎ is‎‎ Aravind‎‎ B‎‎ N,‎‎ and‎‎ I‎‎ work‎‎ at‎‎ "Luxoft‎‎ India"‎‎ as‎‎ a‎‎ Junior‎‎ Software‎‎ Developer.‎‎ Luxoft‎‎ has‎‎ given‎‎ me‎‎ several‎‎ opportunities‎‎ to‎‎ work‎‎ on‎‎ various‎‎ projects,‎‎ which has inspired me to discuss the important processes involved in developing and learning the Universal Measurement and Calibration Protocol in detail Part-1. This is part 2 continuous part of Universal Measurement and Calibration Protocol

Model‎‎ of‎‎ communication‎‎ XCP
Communication, in the XCP model involves the interaction between a master and slave through exchanging data using a message based approach. This method includes encapsulating the XCP message frame within a transport layer frame, including the XCP header and tail. It is commonly seen in XCP implementations on Ethernet with UDP protocols

The diagram illustrates that‎‎ XCP‎‎ Packet

The structure of an XCP packet consists of three elements regardless of the transport protocol used; the Identification Field, Timestamp Field and Data Field. Each element starts with a Packet Identifier (PID) for identification purposes.

Data exchange in XCP occurs between a master and slave on either a frame or packet basis. This exchange involves two types of communication; Command Transfer Objects (CTOs) for command exchange to establish connections between master and slave and Data Transfer Objects (DTOs) for exchanging measurement and stimulation data. Both methods ensure that the slave responds with either RES or ERR as necessary.

The abbreviations mentioned here refer to terms or concepts;

Send commands using CMD Command Packets.
Receive command responses using RES Command Response Packets.
Obtain answers through packets.
Receive error responses through ERR Error Packets.
Manage events using EV Event Packets.
Make service requests using SERV Service Request Packets.
Transmit measurement data via DAQ Data Acquisition.
Stimulate the slave with STIM Stimulation commands.
Perform debugging tasks through DBG Debugging via XCP slaves.
Flash new data into control units indicated by PGM Programming status changes.
Change calibration pages, with CAL Calibration/Paging switches.

XCP‎‎ Master-Slave‎‎ Status‎‎ Exchange

In electronic control units (ECUs) the XCP slave and the ECU application can function independently. The XCP slave may remain active when the ECU application is not running or it may be inactive. It communicates its status to the XCP master using the GET_STATUS command. The XCP slave shares information, about its status, protected resources, authentication, through seed and key and other relevant details. If the XCP slave is capable of sending event messages it will transmit an EV_ECU_STATE_CHANGE event to the XCP master allowing the master to obtain updated details using the GET_STATUS command.

Mode‎‎ of‎‎ Standard‎‎ Communication

The diagram illustrates the‎‎ standard‎‎ exchange

The individual, in charge initiates a request. Awaits the response, from the subordinate before issuing another directive.

Mode‎‎ of‎‎ Master‎‎ Block‎‎ Transfer

The diagram illustrates the Master Block Transfer Mode

where the master can issue commands to a slave without waiting for responses. The block transfer mode is an option to speed up data transfers. Its crucial to consider performance factors and communication settings like time intervals, between commands and the maximum number of commands sent before receiving a response. The master has the ability to obtain these configurations from the slave by utilizing the GET_COMM_MODE_INFO command.

Mode‎‎ of‎‎ Slave‎‎ Block‎‎ Transfer

The diagram illustrates the Mode‎‎ of‎‎ Slave‎‎ Block‎‎ Transfer

Next we have the Slave Block Transfer Mode depicting how the slave can send frames to the master to optimize time especially when updating data status. The command used for this is UPLOAD, in XCP. It's worth mentioning that the restrictions discussed for Master Block Transfer Mode don't come into play when we talk about Block Transfer Mode from the masters end as the master consistently delivers performance.

Mode‎‎ of‎‎ Interleaved‎‎ Communication

Lastly we have Interleaved Communication Mode illustrated in another diagram.

In conversations we often pause to let each other speak before responding. However in communication mode data transmission happens faster as the master can send requests one, after another while considering the buffer size of the slaves. Similarly slaves can respond consecutively without restrictions from the master. It's worth noting that this mode cannot coexist with block mode since it is optional and not relevant.

In XCP there are three modes. Standard, Block and Interleaved. That facilitate the exchange of commands and responses between the Master and Slave.

The CAN communication model adheres to a standard where each request to a Slave elicits one response. This ensures that each XCP message can be easily traced back to its Slave.

While the block transfer mode is optional it proves advantageous, for handling data transfers involving amounts of data. However performance considerations should be taken into account when utilizing this mode. Specific time intervals (MIN_ST) should be maintained between commands and the total number of commands should not exceed a set limit (MAX_BS). The Master can obtain communication settings from the Slave using the GET_COMM_MODE_INFO function. Nevertheless these limitations do not apply to block transfer mode as PCs typically have capabilities to manage data from a microcontroller.

Interleaved mode can also be selected as an option. It doesn't hold importance.

This‎‎ concept‎‎ will‎‎ be‎‎ covered‎‎ more‎‎ in‎‎ the‎‎ next‎‎ article,‎‎ with‎‎ examples.

Do‎‎ let‎‎ me‎‎ know‎‎ if‎‎ you‎‎ have‎‎ any‎‎ queries‎‎ in‎‎ the‎‎ comments‎‎ below.

Thanks‎‎ for‎‎ reading.

Understanding AUTOSAR; Developing Vehicle Software with a Clear Explanation Part-2

Aravind B N — Wed, 07 Feb 2024 14:22:29 +0000

"Functional Software Development"

In the stages the vehicles functional software is described as a system. This system is further divided into sub functionalities known as SWCs(Software Components). These Software Components exchange information (Data Elements), with SWCs through predefined interfaces (Ports).

In a sense the entire communication between the Software Components is managed by the VFB. Since it hasn't been determined yet which software component is assigned to which Electronic Control Unit this perspective is purely logical. The VFB represents communication within and, between ECUs without any knowledge of the underlying technologies. This allows for development and utilization of application software regardless of the hardware.

Once all SWCs and interfaces are established and defined they are distributed to their ECUs.
First the ECU specific RTE implements the Virtual Functional Bus(VFB). The Run-Time Environment is responsible, for managing communication between software components and with the assistance of the operating system handles the execution of these components.

A Runnable Entity serves as the execution unit. Is ultimately implemented as a C function. The developer configures function calls to these entities, which are later executed by the RTE. For instance this could occur periodically or spontaneously in response, to receiving a data element.

For communication interfaces AUTOSAR provides ports. There are two methods distinguished in this context;

In SR(Sender Receiver) communication data elements are sent from one software component to another. This form of communication is widely utilized among application software components.
Syntax example; When it comes to CS (Client Server) communication the Client can initiate a call, to a Servers operation either asynchronously or synchronously. This can be likened to a function call. Is commonly used between applications and Basic Software services such as diagnostics and memory management.

Syntax example; In order to perform an operation the SWC interfaces with its runnables, which are detailed in a created SWC Description. However AUTOSAR does not provide any capabilities, for describing the behavior.

This image demonstrates how logical system components are mapped to hardware components, within the software architecture specifically in the AUTOSAR framework.

On the side of the image there are two boxes labeled "logical" representing logical software components. One box is labeled "Door". The other is labeled "Light." These boxes represent the software functionality for controlling a door and a light. Below these components there is a dashed outline labeled "VFB," which stands for Virtual Functional Bus. The VFB serves as a layer within AUTOSAR that enables software components to communicate with each other in a hardware manner. The icons, below the components depict sensors or actuators associated with the door and light functions.

On the side of the image you'll see two gray boxes labeled "physical." These represent the hardware units, in a vehicle; one is for the Door Electronic Control Unit (ECU). The other is for the Roof ECU. An ECU is responsible for running software components in a vehicle. Within each ECU box there are boxes that correspond to the components mentioned on the left side. For example "Door" is within the "Door ECU" box and "Light" is, within the "Roof ECU" box. This demonstrates how logical software components are allocated to ECUs.

Underneath the software components, within the ECUs there is a designated area called "RTE" which stands for Runtime Environment. The RTE plays a role in the AUTOSAR architecture by implementing the Virtual Function Bus (VFB) on an ECU. Its main function is to establish communication interfaces between software components and the underlying hardware as facilitating communication between different software components within the same ECU or, across multiple ECUs.

The arrow connecting the physical sides represents the process of linking the components to the physical ECUs. This step plays a role, in software development as it determines how software functions are distributed among different ECUs in a vehicle. The mapping process takes into account factors like ECU resources, communication bandwidth and system latency to ensure performance and efficiency of software functions, in the vehicle.

In this image two different approaches, to software development for a Door Electronic Control Unit (ECU) are compared. On the side we see a method without AUTOSAR while on the right side we have an approach that incorporates AUTOSAR.

The left portion of the image represents the software development approach for a Door ECU. It includes a block called "Main Function" which represents the functionality of the software. Below this block there are three interfaces; DIO (Direct Input/Output) μC (Microcontroller) and CAN (Controller Area Network).

On the side of the image there is a code snippet written in C language (fct_Door_Left). This function is called cyclically by the program loop. It interacts directly with the hardware. It reads the state of the door from an I/O port (ReadIOport). Sends a message, over the CAN network (SendCANmessage).

When it comes to AUTOSAR there's an approach shown on the side of the image for the Door ECU. In this approach the software component (SWC) is identified as "Left Door." The block labeled "Runnable; Door Left" represents a piece of code that runs periodically specifically every 100 milliseconds as indicated in the code snippet. The RTE (Runtime Environment) block serves as the AUTOSAR layer that separates hardware details, from software components enabling hardware software development. Below the RTE you'll find layers such, as IoHWAb (I/O Hardware Abstraction) PDU (Protocol Data Unit) COM (Communication) and DIO DRV (Direct Input/Output Driver). These layers abstract the hardware interfaces.

The code snippet, on the right demonstrates a function called "Door_Left" that follows AUTOSAR standards. This function utilizes RTE calls like "Rte_Call_DoorIOState_Op_Get" and "Rte_Write_DoorState_Door" to interact with the door state. These RTE calls provide an abstraction layer allowing for portable software development by abstracting direct hardware manipulation.

The image illustrates the contrast, between embedded software development, where software is closely tied to hardware and AUTOSAR based development. In AUTOSAR based development software components are decoupled from the hardware through interfaces and abstraction layers. This approach enables reusability, maintainability and scalability of applications.

Understanding AUTOSAR; Developing Vehicle Software with a Clear Explanation Part-1

Aravind B N — Wed, 07 Feb 2024 14:15:35 +0000

Formats for AUTOSAR Exchange

The AUTOSAR framework defines exchange formats.

SWC Description; The supplier or OEM is responsible, for defining the SWCs. This involves creating an XML file for each SWC, known as the SWC Description. It provides details about the interfaces and resource requirements of the SWC. Afterwards the supplier or OEM generates the C files to implement it.

System Description; The OEM begins by defining the content, for the vehicle independent of individual ECUs based on the SWCs. Subsequently they design communication networks. Distribute the SWCs to existing ECUs. The outcomes are then recorded in the system description.

According to AUTOSAR 4.0 the OEM simplifies the system description, for each ECU into a condensed version called the System Extract of System Description. This condensed file can be shared with the suppliers of the ECU replacing the used.dbc, FIBEX or.ldf files for BSW module configuration.

To generate an ECU Extract of System Description (ECUEX) a process known as "Flattening" is employed. This process aligns with the System Extract. Only includes the software components (SWCs), in a straightforward manner. The Tier1 supplier has the option to expand the ECU Extract by adding their SWCs that were developed in house.

AUTOSAR 3; ECU Extract of System Description;
For each ECU the OEM condenses the System Description into an ECU Extract of System Description. This condensed file is then provided to the ECU suppliers of using.dbc, FIBEX or.ldf files, for BSW module configuration.

Complete Electronic Control Unit(ECU) Extract of System Description;
beginning with the system description provided by the provider for the ECU extract incorporates their SWCs. The outcome is an updated ECU(Electronic Control Unit) Extract of System Description that includes descriptions for all SWCs on an ECU, from both the OEM(Original Equipment Manufacturer) and the supplier.

The BSW(Basic Software) Module Description files serve as a requirement, for ECU configuration. They contain the definitions of data structures and all configurable parameters of a Basic Software module. These files are implementation specific and along with the generators form part of the code content, in the BSW modules provided by the AUTOSAR stack supplier.

The initial creation of the ECU Configuration Description (ECUC) is done by the supplier, who relies on both the ECU Extract of System Description & the BSW(Basic Software) Module Description files. The supplier then proceeds to configure the ECU using this ECUC for documentation purposes. This involves utilizing tools to set and verify the parameters of the Basic Software modules and RTE. The ECUC serves as a foundation, for generating RTE & BSW modules specific to the ECU accomplished through associated generators.

The flexibility of the AUTOSAR method ensures its suitability for meeting requirements across projects and OEMs. For instance, in the System Description the use of software components is not mandatory.

The image appears to show a flowchart or diagram that explains how software components, for electronic control units (ECUs) are developed using the AUTOSAR (AUTomotive Open System ARchitecture) methodology. AUTOSAR is an architecture for software that enables the interchangeability and compatibility of software components within vehicle ECUs.

Here's a step-by-step breakdown of the diagram

Step 1; Defining Software Components (SWC); The process starts by defining software components using development tools. These components are described in.c/.h files (source and header files, in C programming language) and.xml files, which may contain configuration or definition data.

AUTOSAR System Development Tools

Step 2.1; Model and Code Generation; A model based development tool is used to create models of the software components and generate the corresponding code.
Step 2.2; Validating the code; Next we proceed to implement and validate the generated code to ensure that it meets all the required specifications. This step also involves using templates. May require working with files that were coded by hand.

Step 3; Distributing software components; After the implementation and validation process we distribute the software components. This means making them available, for integration into the system.

Step 4; Defining the network; We define the network in which these software components will operate. This includes specifying how different Electronic Control Units (ECUs) and components will communicate with each other.

Step 5; Involvement of OEM (Original Equipment Manufacturer); The OEM plays a role, in generating the system description, which provides a high level overview of both system requirements and architecture.

Step 6; Extracting ECU Requirements; We extract the requirements of an Electronic Control Unit from the overall system description outlining its responsibilities within the vehicles network.

Step 7; Configuring. Bsw; We configure the RTE (Runtime Environment) and BSW (Basic Software). The RTE acts as a middleware that enables communication, between software components while the BSW provides services like diagnostics, communication and memory management.

Step 8; Generating. Bsw; Based on the configurations we generate the RTE and BSW. These components are crucial for ensuring functionality of software within the ECU.

Step 9; Tier 1 Supplier; This term likely refers to a supplier in the industry. A Tier 1 supplier directly supplies, to OEMs (Original Equipment Manufacturers). The responsibility of a supplier is to deliver BSW module descriptions and configuration files.

⁤The diagram also illustrates how information flows between these steps with arrows indicating the direction of the workflow. ⁤⁤The presence of .xml/.c/.h and.a2l files implies that the process combines configuration, programming and potentially calibration or parameter definition activities. ⁤

AutoSAR Testing, Tool, Migration Overview

Aravind B N — Sat, 27 Jan 2024 14:54:12 +0000

AutoSAR Tools

There are tools employed in developing AUTOSAR ECU software. These tools are categorized into the following types;

Tools for system design

Tools, for system design; these help in defining the network architecture, communication & also assist in the design and distribution of software of the software components (SWCs).
Tools for configuration of the software and RTE; Additionally these tools aid, in generating a configuration description of the BSW modules in the Electronic Control Unit (known as ECU Configuration Description).
Code generators for BSW modules; Through code generators that are based on the Electronic Control Unit Configuration Description. produce configured Basic Software (BSW) modules, for the Electronic Control Unit.

These tasks are usually handled by tools. Hence an important aspect of AUTOSAR involves a XML format that can be used as the foundation, for exchanging design & config1uration data b/w tools.

Standardization plays a role because development projects often involve using tools from manufacturers. For instance the microcontroller independent BSW may be provided by one software company while the MCAL and its associated code generators are developed by the semiconductor manufacturer.

In some cases each BSW module might even require a tool. However it is generally recommended to use a tool, for configuring the BSW in scenarios.

AutoSAR Migration Solutions

The AUTOSAR standard enables the migration of ECU software that was not originally developed according to the AUTOSAR method, into the AUTOSAR environment. To facilitate this AUTOSAR provides a Complex Driver, which can be regarded as a type of software component that does not necessitate a formalized description following the SWC template.

This can be perceived as a kind of software component (SWC) that does not necessitate a description using the SWC template.

A Complex Device Driver can directly access the AUTOSAR software without relying on the RTE. This means that, from the applications perspective only the basic software undergoes changes while the application itself can mostly remain unchanged. In the context of migration we can also view the application as a device driver. This can be seen as a step towards an AUTOSAR software architecture, which is considered to be the cost effective approach, in terms of development effort.

By adopting this approach we can already start benefiting from AUTOSAR functionalities. For example we can periodically call upon parts of the application through the RTE. Utilize communication and diagnostics services via the RTE while keeping implementation of our application core AUTOSAR compliant.

In the run we remove the parts of the application that don't adhere to AUTOSAR. Specifically we eliminate all task bodies. Calls, into the operating system well as any points with interrupt blocking and other basic software accesses. We replace them with elements that're compliant with AUTOSAR standards. By using a design approach we can implement these application portions more efficiently, than before.

AUTOSAR ECUs Testing

During the testing phase the same approaches can be applied to AUTOSAR ECUs as those used for Electronic Control Units, with different internal software architectures. When we view the ECU as a box we only need to consider the following aspects;

Network Management (NM):

AUTOSAR makes use of a Network Management Protocol that differs from hired protocols like OSEK Network Management. In our take a look at surroundings it's far important to remember this NM protocol and make certain that we adequately take care of and process the messages, at the network channels.

File Formats for Network Communication Description: The System Description includes a description of network connectivity in AUTOSAR. earlier forms such, as.dbc, FIBEX or.ldf (depending on OEM requirements) have been replaced by a format. The test environment should be capable of processing this format.

AUTOSAR gives a software program structure that brings an advantage, for trying out and debugging ECUs. This shape ensures the availability of nation variables in every AUTOSAR Electronic Control Unit, which may be used within the testing surroundings.

For instance the ECU state is available through the EcuM module while communication states of network channels within the ComM module's storage. By implementing BSW modules these state variables can be accessed via an XCP connection to the Electronic Control Unit whether it's through an interface for debugging or one of the networks like JTAG or Nexus. BSW generators can provide an A2L description file that corresponds to these state variables. Alternatively AUTOSAR offers a Monitoring & Debugging protocol specifically designed for this purpose.

AUTOSAR also provides advantages when it comes to accessing the application level. For instance the Runtime Environment (RTE) can be generated in a manner that enables access, to the data, between the SWCs. Additionally the Runtime Environment (RTE) generator can produce an A2L file.

In Conclusion;

AUTOSAR takes an approach to develop ECU software offering tools, for system design, software configuration and code generation. These tools establish a foundation for automotive systems. AUTOSARs migration solutions utilize Device Drivers to integrate existing software into the AUTOSAR environment. The standardized internal software architecture ensures access to state variables, which greatly benefits testing and debugging processes. Overall adopting AUTOSAR not streamlines development processes. Also showcases the automotive industrys commitment to reliability, efficiency and adaptability. This represents an advancement, in the evolution of ECU software.

Classic AutoSAR Basic S/W and Runtime Environment (RTE)

Aravind B N — Mon, 22 Jan 2024 03:57:43 +0000

Hello Readers,‍‍‍‍‍‍‍‍󠁲
My name is Aravind B. N., and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to discuss the important processes involved in learning the Autosar Basic s/w and Runtime Environment (RTE).

Introduction

Before going to the topic, let's know the simple basic concept of the AutoSAR layers.

Application layer:
The Application Layer is responsible, for executing the application functionality of the Electronic Control Unit. It comprises software components.

Service Layer:
The Service Layer offers a variety of background services, such, as memory management and bus communication services. Additionally, the operating system is included within this layer.

ECU Abstraction Layer [ECUAL]:
The Electronic Control Unit (ECU) Abstraction Layer provides a consistent way to access all the features of an Electronic Control Unit, including communication, memory and I/O. This applies regardless of whether these functionalities are integrated within the microcontroller or implemented through peripheral components.

Microcontroller Abstraction Layer [MCAL]:
The Microcontroller Abstraction Layer consists of drivers that are specifically designed to interface with the microcontroller's memory, communication and I/O functionalities.

Complex Device Drivers [CDD]
The Complex Drivers contain the drivers for the soecific properties of a microcontroller or Electronic Control Unit (e.g. complex peripheral devices) which are not standardized in AUTOSAR. They comprise functions for sensor evaluation and controller monitoring with
direct access to the microcontroller.

Basic Software:

An AUTOSAR system is described using Software Components, which are connected through the VFB (or ECU RTEs). This abstraction may give the impression that AUTOSAR Basic Software solely focuses on communication. However, this is not true.

AUTOSAR Basic Software also offers Electronic Control Unit services such, as state management (ECU state and control of communication channels) diagnostic services, watchdog services, operating system functionality and management of nonvolatile memory. Even input/output (IO) is included within the scope of AUTOSAR standardization.

Semiconductor manufacturers play a role in the standardization of the topic, input and output. They supply the low-level software layer (MCAL). As a result of this standardization certain issues that were previously handled by Electronic Control Unit suppliers now fall under the responsibility of software suppliers.

The graphics (as shown in the above figure), on the demonstrate the software architecture of MICROSAR, which's the Vector implementation of the AUTOSAR Std.

The Basic Software's attributes

Software components can only adopt abstraction if the necessary mechanisms are available, from the Basic Software (BSW). To achieve this the BSW complements the Runtime Environment (RTE) by providing these mechanisms. This is especially evident in terms of the communication stack and operating system which are closely intertwined with the RTE and its functioning.

For instance the BSW is responsible for generating events and supplying timers for the RTE. It also facilitates data transfer across Electronic Control Unit boundaries through communication buses. As for executing Runnable Entities within software components both flow control and system state management fall under the purview of software. Additionally it offers synchronization primitives to ensure access, by processes.

Runtime Environment:

Optimal Configuration Overview
The efficient Run Time Environment (RTE) is required to implement the communication and call mechanisms described in the Software Components. When formal descriptions of the SWCs are available it becomes possible to analyze the software design and derive, generate and optimize the runtime environment.

The formalized description of a software design includes information, about how a Runnable Entity's called within its context and how it interacts with parts of the same SWC or another SWC. By considering constraints, like the configuration of the software decisions can be made regarding the optimal implementation of a function call.

To effectively manage the system, we need to make decisions, about.

Choosing a method to prevent access, from running entities if necessary.
Deciding on the method of making calls.
Direct calls (like a macro or C function call)
Calls triggered by an RTE Event in conjunction, with the operating system.
Determining the type of write or read access.
Accessing a Calling an API of the Basic Software.

Calls can be made either directly like a macro or C function call or through an RTE Event triggered alongside the operating system.

We also need to consider the type of read or write access required. This could involve accessing a variable or making API calls in the Basic Software. It's important to consider the semantics of access types and how they are implemented.

The specific configuration will determine the impact of these decisions, on performance.

Generally the generator, in the runtime environment should minimize its reliance, on OS events and alarms. By configuring the system appropriately valuable resources can be. Execution time can be reduced. To achieve this it is important to comprehend the impact of design choices made during the software components design phase.

Basic S/w Dependencies on original equipment manufacturers

One characteristic of AUTOSAR software is its modular nature. This modularization occurs both horizontally dividing it into task areas or clusters and vertically splitting it into abstraction levels or layers. AUTOSAR allows for levels of granularity, in the Basic Software, known as Implementation Conformance Classes (ICC). This flexibility enables the combination or clustering of BSW modules ranging from a software consisting of just one module to a comprehensive basic software covering all functionalities.

It's important to note that AUTOSAR Basic Software is not necessarily specific to an Original Equipment Manufacturer. However there are aspects where the BSW stacks of Original Equipment Manufacturer's typically differ.

For instance these stacks may vary in terms of the number and task areas allocated to BSW modules that're not part of the standard AUTOSAR. Additionally there might be extensions, in the form of Software Components added to the AUTOSAR Basic Software stack.
In the structure of the Basic Software there are variations, in the following areas;

Diagnostic Event. Diagnostic Communication Manager
Handling of communication channels
Network management
Gateway functionality for communication
Specific services like encryption modules and proprietary transport protocols

When it comes to configuring the Basic Software there are also differences in work processes among Original Equipment Manufacturer's;

The way Original Equipment Manufacturer requirements are provided (such as.dbc file, ECU Extract of System Description or separate SWC descriptions)
Diagnostics layout and parameter setting (using ODX, CANdela file, etc.)
General requirements, like build configuration capability of the communication stack and delivery of libraries to suppliers

The graphics (as shown in the top figure), on the demonstrate the software architecture of MICROSAR, which's the Vector implementation of the AUTOSAR Std's.

Basic Software Origins

Suppliers have approaches when it comes to handling the software among Original Equipment Manufacturers.

For instance there are models where the Original Equipment Manufacturer has already obtained the rights to the hardware components of the fundamental software, from a specific software producer. In situations the supplier only needs to acquire the hardware components. On the hand in some cases the Original Equipment Manufacturer supplies the supplier with pre integrated basic software packages, for various target platforms without any cost involved.

In some cases the Original Equipment Manufacturer specifies the functionality of the software modules, for other models. However they leave the implementation and integration of the Electronic Control Unit up, to the supplier. The supplier then has the flexibility to procure these modules from software producers. Integrate them into a comprehensive basic software package on their own.

Some major suppliers have developed their versions of AUTOSAR software and therefore also serve as software producers for these, in house developments. Depending on the relationship, with the Original Equipment Manufacturer there may be negotiations needed regarding the utilization of this software.

XCP - Universal (X) Measurement and Calibration (C) Protocol (P).

Aravind B N — Mon, 08 Jan 2024 15:43:23 +0000

Hello Readers,
My name is Aravind B N, and I work at "Luxoft India" as a Junior Software Developer. Luxoft has provided me with numerous opportunities to work on challenging projects, which has inspired me to discuss the important processes involved in developing and learning the Universal Measurement and Calibration Protocol in detail.

Introduction

When it comes to tuning ECUs the process of parameterization plays a role. It entails making adjustments, to the parameter values while the system is operational and gathering measured signals simultaneously. To establish a connection, between the development tool and the ECU, a measurement and calibration protocol called XCP is commonly used as an accepted standard. In this explanation we will delve into the fundamentals and mechanics of XCP as explore its application areas and how it enhances ECU calibration.

XCP, additionally known as Universal Measurement and Calibration Protocol is a protocol that became evolved by means of the Association, for Standardisation of Automation and Measuring Systems (ASAM). ASAM consists of car manufacturers, vendors and device manufacturers. XCP replaced the CAN Calibration Protocol (CCP) which furnished get admission to to ECU statistics through CAN for each studying and writing purposes. The motive in the back of developing XCP become to permit this capability using transmission media which include CAN, FlexRay or Ethernet. The number one applications of XCP include measuring and calibrating ECU parameters to make certain data, across ECU procedures.

Let's start with some XCP facts:
The idea, behind XCP (X Case Process) is a tool that allows developers to gain insights into the ECU and its software like looking inside a box. This enables developers apprehend how the ECU behaves for the duration of every computation cycle enabling them to optimize algorithms and perceive regions for development. XCP can be used to test the functionality of the improvement development whether or not its running on hardware or primarily based on models. This approach significantly contributes to the development procedure.

The important awareness lies in evaluating the procedure in improvement environments like Simulink. Developers can analyze parameters at some point of version runtime or after engaging in checks to attain results. It's critical to have get admission to, for making parameterization modifications. The number one objective is. Optimizing thru parameterization modifications.

The interface model of ASAM
The ASAM interfaces version defines XCP, which incorporates interfaces to the dimension and calibration device, description document, and higher-stage automation gadget.

The "ASAM MCD-1 MC" interface, among ECU and dimension & calibration system, describes bodily and protocol-particular parts. However, it in no way obtained general recognition and has no relevance today. The XCP protocol is flexible enough for producer-impartial interfaces, making ASAP1b needless.

The "ASAM MCD-2 MC" A2L ECU description file is a necessary file for users to work with symbolic object names, as XCP operates in an address-orientated manner, making it inconvenient to look for ECU gadgets based totally on addresses.

The "ASAM MCD-3 MC" automation interface connects a system to a size and calibration device, however isn't always defined in this report because of its beside the point nature.

XCP is a measurement and calibration protocol based at the Master-Slave principle, wherein the ECU is the Slave and the dimension and calibration tool is the Master.

Several individuals can communicate with an authority simultaneously taking into account data and access, to settings throughout the development process. This eliminates the need for duplication of configurations. Streamlines iterative loops. XCP solutions are already employed in work settings. This book aims to elucidate the fundamental characteristics of the measurement and calibration protocol and introduce its application in different operational contexts. It does not provide XCP specifications or instructions, for integrating XCP drivers into environments.

In this e book we utilize the CANape measurement and calibration tool offered by Vector to capture screenshots of the PC device in use. Moreover it provides insights, into system processes including the creation of an A2L file. You can access a free demo version of CANape on Vectors Download Center, at www.Vector.Com/canape_demo.

The fundamentals of the XCP protocol

The XCP Protocol is a fundamental device used for transferring facts between computers.

The XCP Protocol, which is part of the ASAM interfaces version consists of protocol and delivery layers. These layers ensure independence from transport methods. The main objectives of this protocol are to prioritize resource efficiency, in plug and play setups, facilitate communication enable implementation for slaves and ensure minimum parameters and scalability for ECUs. The design aims to achieve optimal resource utilization, efficient communication and straightforward implementation, for slaves.

XCP protocol, which has been extended to new shipping layers on the grounds that 2005, is called XCP on CAN or Ethernet. Its contemporary version, Version 1.Three, changed into permitted in 2015.

XCP is a key functionality that lets in study and write get right of entry to the reminiscence of the Slave.

Read access lets in users to evaluate an internal ECU parameter's temporal response, which changes at particular intervals whilst the processor recalculates and updates it in RAM. One of the strengths of XCP is a obtaining measured data from RAM that exchange synchronously to system flows or occasions inside the ECU, permitting users to evaluate direct relationships among time-primarily based method flows and converting values.

Write access permits customers to optimize parameters of algorithms in the Slave, with accesses being cope with-oriented. A parameter measurement is initiated by the Master and requested by the Slave at the same time as calibration includes placing the price at deal with 0x9876 to 5.

This concept will be covered more in the next article, with examples.
Do let me know if you have any queries in the comments below.

Thanks for reading.

Understanding J1939 SAE Protocol: The Complete Guide to Communication in Commercial Vehicles. Part-3

Aravind B N — Tue, 12 Dec 2023 15:28:33 +0000

Structure
The J1939 21 document outlines the way in which the 29 bit CAN identifier should be understood. Just like how a CAN messages 8 byte data field has start bits and lengths to define signals the CAN identifier is divided into segments, for a parameter group. This means that only A part of the identifier represents the PGN itself while the rest is used to determine source address, destination address, priority and data page. The diagram titled "From the 29 bit CAN Identifier to the Parameter Group" illustrates how a J1939 CAN identifier is structured.

PGN Format
The diagram illustrates that the PDU Specific section can be interpreted in ways. This section serves two purposes; it extends the PDU Format section. Defines a PGN while also specifying a destination address. The rules, for this are as follows;

If the value in the PDU Format section is than 240 then the content of PDU Specific is treated as the destination address. This is referred to as a PGN in PDU Format 1 or a specific PGN. A PGN in PDU Format 1 can be sent directly to a destination address using point, to point communication. It can also be sent globally using the global address (255). In this way a specific PGN can be transmitted globally to all network nodes.

If the value of the PDU Format segment is equal, to or greater than 240 it indicates that the PDU Specific segment functions as a group extension. In this scenario there is no destination address. The message will be transmitted to all network nodes. The PDU Format and PDU Specific together form a 16 bit value that corresponds to the Parameter Group Number (PGN). In the case mentioned, where the PDU Format is 2 it is referred to as a PGN.

How certain PGNs are depicted in the absence of address data required? According to the specification in cases '00' replaces the address information in order to extend the PGN. Therefore;

If the portion in PDU format includes '0xEE' then the corresponding PGN would be '0xEE00'.

This approach defines a range, for PGNs as depicted in the "PGN Value Range" graphic.

The PGN includes two bits called "Data Page" and "Extended Data Page," which can be moreover counted because the essential info. Consequently, the sort of numbers is divided into four PGN pages. Only 3 of them are applied in J1939.

The general number of PGNs may be decided as follows: (240 (+ (16x 256)) x 3).

Here are the available definitions, for each data page;

Here's an example of a Group of Global Parameters
Below is a PGN that represents parameter groups in the J1939 standard, commonly used in the industry.

Global PGN;

PGN 65262 | Engine Temperature | ET1

Transmission Rate; 1 second
Data Length; 8 bytes
Data Page; 0
Extended Data Page; 0
PDU Format; 254
PDU Specific; 238
PGN Supporting Information; Optional (if
Default Priority; Priority level 6
Parameter Group Number; 65262 ( representation. 0x00FEEE)
Start Position Length Parameter Name SPN
1 1 byte Engine Coolant Temperature SPN 110
2 1 byte Engine Fuel Temperature 1 , SPN 174
3 4 2 bytes Engine Oil Temperature SPN 175
5 6 2 bytes Engine Turbocharger Oil Temperature SPN 176
7 1 byte Engine Intercooler Temperature SPN 52
Please observe that every one the parameter businesses mentioned in the J1939 71 document were consolidated right into a table called J1939 DA.

Lets check an instance collection of parameters;

PGN 54528 also called Time/Date Adjust or TDA follows the representation of parameter organizations mentioned within the J1939 popular.

Here are the details of this PGN;

Transmission Rate; As wanted

Date Length; 8

Data Page; 0

Extended Data Page; 0

PDU Format; 213

PDU Specific; DA

PGN Supporting Information; Please talk to Appendix D, PGN 65254.

Default Priority; 6

Parameter Group Number; 54528 (0x00D500)

Lets spotlight some parameters regarding time and date adjustment;

Adjust seconds; Utilize this parameter to exchange the seconds value.
Adjust mins; Modify the mins price using this parameter.
Adjust hours; This parameter allows you to make changes, to the hours.
Adjust month; Use this parameter to exchange the month.
Adjust day; Modify the day cost the use of this parameter.
Adjust close by minute offset; Utilize this parameter to alter the minute offset.You can alter the hour offset through using this parameter.

Below are some key Parameter Groups (PGNs) and their descriptions as said in record J1939 80-one.

Address Claimed (PGN 0x00EE00); This is used to pick out an ECU and come across cope with conflicts.
Commanded Address (PGN 0x00FED8); This network service assigns tool addresses, to ECUs.
Name Management (PGN 0x009300); This network provider is used to assign and modify the device call (NAME) of an ECU.

Please observe that Remote Frames aren't supported in J1939. The Request PGN refers to a CAN statistics body.
Under the J1939 21 standard there are Manufacturer definable PGNs, such, as Proprietary A with identifier 0x00EF00 and Proprietary A1 with identifier 0x01EF00. Additionally there is a PGN range of 256 PGNs defined as Proprietary B with identifiers ranging from 0x00FF00 to 0x00FFFF.

Data Content
In the context of J1939 not are the PGNs defined but their contents. These message contents are commonly referred to as signals, in languages. According to the J1939 specification the term used for describing the contents of a PGN is Suspect Parameter Number (SPN). An SPN essentially represents a signal ID. Can represent values, statuses or commands. SPNs are also defined for protocol information. The J1939 DA currently lists all specified SPNs in table form. An SPN is a number provided by the SAE. The position of the SPN, within a PGN is specified in the PGN description (refer to chapter (A Global Parameter Group example). When interpreting the SPN we start from the right (LSB). Move towards the left (MSB) except for data. It is possible for an SPN to be present in PGNs.

Each SPN has a format and includes the following attributes;

SPN; Suspect Parameter Number and Name
Description; Provides an explanation of an SPNs function
Data Length; Indicates the length of data in bits or bytes
Resolution; Describes how to convert raw values into physical values
Data Range; Specifies valid physical value ranges
Type; Identifies signal types, such as measured, status or application dependent signals
PGN Reference; Refers to the PGN(s) where the specific SPN occurs

This is identified by the J1939 standard's SLOT 3 specification (The scaling, Limitation, offset, & Transfer Functions) presentation as the description, for each presented SPN.

Value Range
Typically when defining a SLOT (Scaling, Limit, Offset and Transfer Function) we don't use the range of values, for an SPN, as the payload. For instance lets consider an 8 bit value (28 = 256) that represents a range of 0...255 values. However Only the range 0....250 is allowed and considered data. The remaining values, in the range from 251 to 255 indicate attributes or conditions of the SPN.

To illustrate this further lets take the example of a limit switch used to represent the status of a door (OPEN/CLOSE). In this case one bit is required to convey the information. The following values have been defined:

OPEN
CLOSE
ERROR
SNA (Signal Not Available)

This technique permits us to discover sensor malfunctions or cable breaks and decrease the risk of misinterpretation. The SNA signal status is utilized when an equivalent variation of the device does not support a signal. Refer to Table 1 for a representation of Table 2 shows the ASCII values. for measured discrete values and Table 3 for discrete commands.

As a rule if every bit in an SPN is configured to '1' it signifies an SNA status.

In the article we will continue exploring this topic with examples.

Thank you for taking the time to read this.

Understanding J1939 SAE Protocol: The Complete Guide to Communication in Commercial Vehicles. Part-2

Aravind B N — Mon, 04 Dec 2023 17:25:37 +0000

Protocol Description in General
SAE
The J1939 standard is broken into several papers and chapters. All papers are available for download from the SAE website, either separately or in preassembled bundles.

www.sae.org.
The J1939 specification's individual chapters are not available for free; instead, there is a fee associated with them. Though you may already be familiar with it from the previous chapter, each chapter is organized methodically and is based in part on the ISO or OSI reference model. Only loosely based, as chapter 8 in the J1939 document format is not specified by the OSI model. The "Numbering scheme" image depicts the chapter organization scheme.

Outlining
A document is present with no number extensions in addition to the structured papers and their appendices. This is the top-level J1939 document, which summarizes all of the protocol's main characteristics. This document's appendices are extremely important. For rapid reference, the manufacturer codes, industry groups, reserved node addresses, parameter groups, and signals are all provided here.

The current chapters and papers are shown in the table.

Addresses and Names

Device Names

Identification An exclusive name is needed for any ECU that actively engages in J1939 communication, or transmitting. This is made up of a 64-bit stream. NAME is the definition of the device name in the standard. It includes details about the device's origin and functionality as well as identification and instantiation information. An ECU may be identified globally and characterized into a unique ECU by using the device name. Furthermore, during the dynamic address assignment process, the ECU is given priority based on its device name (see to Chapter Network Management for more information).

Figure "64bit ECU Fields" shows how the J1939 NAME is constructed.

Device Address

Node Addressing
Information about the message addressing type is provided by the CAN protocol. This implies that all data is labeled with an identifier and may be processed and assessed in this manner. J1939 has both message addressing and node addressing, which are implemented as software. This enables point-to-point communication. Within a J1939 n/w, a node address is assigned to each bus node for this purpose.
A message gadget called CAN is employed in lots of exceptional fields, along with business manage, constructing automation, and the automobile industry. The protocol relies on nodes—devices related to the community—replacing messages, or packets, as a way to transmit statistics.
A message's supply cope with, vacation spot deal with, data period, and content are all included. While the supply cope with identifies the tool that sent the message, the destination deal with defines the tool to which the message is sent. While the statistics contains the real message payload, the facts length specifies the records's duration in bytes.
Using message addressing, messages are sent via a common conversation channel in a CAN community. J1939, a widespread for the electronic control unit (ECU) in automotive packages, uses this type of addressing. J1939 supports message addressing, which is a software-primarily based addressing scheme that permits factor-to-point communication between nodes.
Message addressing is used to guarantee that messages reach the intended recipient node and to keep away from message duplication or resend, that could lead to extra troubles which includes community congestion. J1939's addressing approach is similar to other messaging protocols like Ethernet and Modbus, which further employ node addressing to transmit source and vacation spot information for messages.
Network Types
Essential: A proper address is required for every ECU that transmits in J1939 n/w. The node address is an 8-bit number that may only be issued to a single node one (static network). However, networks may be built in which nodes autonomously seek for their addresses (dynamic network). It is up to each application which such the two types of networks are utilized.
Static
When a truck's drive train use the J1939 protocol in its traditional definition, a network that is static is often discovered, where the addresses and network topology were predetermined at the time the vehicle was built. The address allocation and topology of such a network stay consistent throughout the vehicle's life cycle.
Dynamic
The topology of dynamic networks can alter during operation. It is possible to add both known and unknown network nodes. Even more than one ECU of the same kind might exist in a network. An instance of a dynamic network in use is the Protocol ISO 11783. which is utilized in agricultural engineering to facilitate interaction b/w an implement and its attachments.

General

PGN
A group of data that share a common transmission rate because they are part of the same context is known as a parameter group. A Parameter Group Number (PGN) is a special number that serves as an identity for each parameter group. It is simple to mistake the parameter group for the CAN identification. This chapter aims to clarify the distinctions between a CAN message identity and a J1939 parameter group. The similarities and differences are seen in the comparison that follows:

Similarities:

assemblage of signals with comparable or same context
able to be recognized by a special number
includes protocol and application data.

Variations:

Not restricted to the top capacity of 1785 bytes (8 data bytes).
able can be sent point-to-point
The message's priority is not reliant on the PGN.

A multi-packet message will be delivered if a parameter group specifies a data length more than 8 bytes. The so-called transport protocol is provided by the standard.

Although The Control Area Network (CAN) protocol specifies how messages are carried and received over the bus, it makes no point out of the way addresses are created or mapped to real bus nodes.

This will be continued in the next article alone, with examples.

If you have any questions, please feel free to ask them in the comment section.

Thank you for taking the time to read this.