DEV Community: S G

Diagnostic interfaces and notification autosar

S G — Mon, 04 Mar 2024 17:56:57 +0000

My name is Sharana Basava, and I work at Luxoft India as a junior software engineer. I have had multiple opportunities to work on different projects at Luxoft, which has motivated me to talk about the crucial steps in creating a diagnostic standard.

introduction Diagnostic Interfaces
To provide the data maintained by the Dem to an external tester the Dem supports interfaces to the Dcm ,Please note, these API are intended for use by the Dcm module exclusively and may not be safe
to use otherwise.In case a replacement for the Dcm module has to be implemented,

Notifications
The Dem supports several configurable global and specific event or DTC related notification functions which will be described in the following. Notification functions will only be called, if the Dem is fully initialized.

Monitor Status Changed
These are notifications for a monitor status change. With the given event ID the receiver is able to identify what has changed.
-> General notification:
This callback function is called from Dem for each event on monitor status change.
-> FiM notification:
This callback function is called from Dem for each event on monitor status change.Dependent on the given state the FiM is able to derive the new fault inhibition state.
Event Status Changed
These are notifications for an event status change independent of the DTC status availability mask. With the given old and new status, the receiver is able to identify what has changed.

-> General notification:
This callback function is called from Dem for each event on event status change Event specific notifications:
Each event may have one or more of these callback functions which are called only if the respective event status has changed.

-> FiM notification:
This callback function is called for each event on event status change. Dependent on the given state the FiM is able to derive the new fault inhibition state. In contrast to the other Event Status Changed callbacks, the FiM is also notified about status changes resulting from disconnecting or reconnecting the event via API Dem Set Event Available()

-> Dlt notification:
This callback function is called for each event on event status change.The event status notifications are triggered from the Dem task function, not directly out of the context of the monitor.
There will be a delay of up to the Dem task cycle time between a monitor report and the change notification. This also affects the function permission calculation in the FiM module which is based on the event status notification

DTC Status Changed
These are notifications for a DTC status change. The DTC status availability mask is taken into account, so status bits which are not supported will not cause a notification. It is also possible
that a changed event status does not change the resulting status of a combined DTC status

-> Global notifications:
The configuration can define one or more of these callback functions which are called only if the respective DTC status has changed.
-> Dcm notification:
This callback function is called for each DTC status change. Dependent on the given state the Dcm is able to decide if a ROE message shall be sent.Changes API Dem_Dcm Control DTC Status Changed Notification is no longer supported and notifications are called always unless caused by Clear DTC.
-> General notification:
This is a single callback function which is called for each event on data change.
-> Event specific notification:
Each event may have one callback function which is called on event data change.

Monitor Re-Initialization
These notifications are called from Dem, to signal to diagnostic monitors that a new test result is now requested. This can happen due to clearing the fault memory, the start of a new operation
cycle, or the re-enabling of previously disabled DTC settings or enable conditions The set of notification calls is fully customizable in the configuration.
-> Event specific notification:
Each event may have one callback function which is called for the reasons mentioned above.
-> Function specific notifications:
Each event may have one or more of this callback functions which is called for the reasons mentioned above. For combined events, this callback is notified for each event if they are re-enabled by enable conditions. Note-Monitor re-initialization callbacks due to an operation cycle restart are called between the end of the previous, but before the start of the new operation cycle. So events cannot be reported at that point of time.

Clear DTC Notification
These notifications will be called from the Dem task function either before or after processing the clear request. This is configurable per notification.
-> Before a clear request is started, i.e. before any DTC is modified or a Clear Allowed callbacks is invoked.
-> After a clear request has finished. This is either after all DTCs have been reset in RAM, or after the cleared NV information was persisted by the NvM. The notification will be triggered before Dcm can send a response.

Indicators
An event can be configured to have one or more indicators assigned· An indicator is reported active if at least one assigned event requests it, and cleared when all events assigned to it have
revoked their warning indicator request (i.e. by healing or diagnostic service Clear Dtc).The indicator status is set always with event confirmation (set condition of bit 3), and reset after
the configured number of operation cycles during which the event was tested, but not tested failed. An event’s warning indicator request status is reported in bit 7 of the UDS status byte·

Introduction about Runtime Environment(Part -2)

S G — Mon, 04 Mar 2024 17:16:33 +0000

continuation of Triggering of Runnable Entities

->Mode Switch Triggered Runnables
AUTOSAR defines the Mode Switch Event to trigger a runnable entity on either entering or exiting of a specific mode of a mode declaration group· The Mode Switch Event can only trigger a runnable entity at its entry point· Consequently, there exists no API to set up a wait point for a Mode Switch Event·

->Mode Switched Acknowledge Triggered Runnables
AUTOSAR defines the Mode Switched Acknowledge Event to signal a successful mode transition· The Mode Switched Acknowledge Event can either trigger the execution of a runnable entity or continue a runnable, which is waiting at a wait point for the mode transition status· Only intra ECU communication is supported·

->Operation Invocation Triggered Runnables
The Operation Invoked Event is defined by AUTOSAR to always trigger the execution of a runnable entity· The signature of server runnable depends on the parameters defined at the C/S port· The return value depends on application errors being assigned to the operation that the runnable represents· The parameter list contains input input/output and output parameters· Input parameters for primitive data type are passed by value· Input parameters for composite data types and all input/output and output parameters independent whether they are primitive or composite types are passed by reference· The string data type is handled like a
composite type·

Multicore support
Similar to the mapping of SWCs to partitions with different memory access rights, the RTE also supports the mapping of SWCs to partitions on different cores for parallel execution·

->Partitioning of SWCs
The mapping of SWCs to cores happens with the help of OS Applications like in the memory protection use case· The user has to assign runnables to tasks and tasks to OS Applications in order to map SWCs to partitions· The OS Applications can then be assigned to one of the cores of the ECU· SWCs can only be assigned to a single OS Application· This means that
all runnables of a SWC need to be mapped to tasks within the same OS Application· If a SWC contains only server runnables that are not mapped to a task, the SWC can be mapped with the help of an ECUC partition·

BSW Access in Partitioned systems
When the SWCs are assigned to different OS Applications, only the SWCs that are assigned to the BSW OS Application can access the BSW directly· SWCs that are assigned to other cores or partitions do not always have the required access rights· The same is true for runnable entities that are directly called by the BSW through client/server interfaces· The RTE can transparently provide proxy code for such BSW accesses but the user needs to map the Send Signal proxy and the server runnables to tasks in which they can be executed·

Inter-ECU Communication
IOCs or additional global RTE variables are automatically inserted by the RTE generator when data needs to be sent from a partition without BSW to another ECU· This is required because the COM APIs cannot be called directly in this case· Instead, the RTE provides the schedulable entitiy Rte Com Send Signal Proxy Periodic for the partition that contains the BSW COM module, which periodically calls the COM APIs when a partition without BSW transmitted data· If the COM is instantiated on multiple partitions for parallel use, then such a schedulable entity Rte Com Send Signal Proxy Periodic is provided on each partition that contains the COM module· In this case the Rte Optimization Mode attribute must be set to RUNTIME as the optimization mode MEMORY would require spinlocks for all bitfield accesses, which would cause too much overhead· Each schedulable entity Rte Com Send Signal Proxy Periodic should be mapped to the same task as the corresponding Com Main Function Tx with a lower position in task so that it can update the signals before they are transmitted by the COM· Rte Com Send Signal Proxy Periodic will be scheduled with the same cycle time as Com Main Function Tx· For this, the RTE generator reads the period from the COM configuration· For the reception of signals no special handling is required· The RTE will automatically forward the received data to the appropriate partition in the COM notifications·

Client Server Communication
Client server calls between SWCs in different partitions are also possible·In order to execute the server runnable in another partition, the server runnable needs to be mapped to a task· The RTE will then make the server arguments available in the partition of the server runnable, execute the server runnable in the context of its task and return the results to the calling partition.Direct client server calls to servers on other cores are not possible because this would enforce that the server is executed in the context of the client core· This would lead to data consistency problems for RTE APIs that only provide buffer pointers like Rte Pim· The RTE cannot use IOCs for these APIs because the actual buffer update is done by the application code. You can instruct the RTE to generate a context switch. You can decide this over the task mapping of a function trigger· If you consider RTE calls which originate from the same partition as the server runnable, a context switch into the task of the server runnable may not be required. Performing a task switch would mean an additional overhead which can be avoided. Therefore, it is also possible to configure an additional server port prototype for clients which are local to the server partition. The triggers from both server ports can then trigger the same server runnable· However, only the trigger from the port that is connected to foreign partitions needs to be mapped onto a task. As a consequence, the RTE can implement calls from partition local clients as efficient direct function calls.Please take into account, that this is only allowed when the server runnable is not invoked concurrently or marked as “can be invoked concurrently”· In addition, you can use Exclusive Areas to protect the runnable against concurrent access problems·

Introduction about Runtime Environment(Part -1)

S G — Mon, 04 Mar 2024 16:46:34 +0000

->Introduction about Runtime Environment
The RTE is the realization of the interfaces of the AUTOSAR Virtual Function Bus (VFB) for a particular ECU· The RTE provides both standardized communication interfaces for AUTOSAR software components realized by generated RTE APIs and it also provides a
runtime environment for the component code – the runnable entities· The RTE triggers the execution of runnable entities and provides the infrastructure services that enable communication between AUTOSAR SWCs· It is acting as a broker for accessing basic software modules including the OS and communication services

RTE functionality overview:
->Execution of runnable entities of SWCs on different trigger conditions
->Communication mechanisms between SWCs (Sender/Receiver and Client/Server)
->Mode Management
->Inter-Runnable communication and exclusive area handling
->Per-Instance Memory and calibration parameter handling
->Multiple instantiation of SWCs
->OS task body and COM / LDCOM callback generation
->Automatic configuration of parts of the OS, NVM and COM / LDCOM dependent of the
needs of the RTE
->Assignment of SWCs to different memory partitions/cores

AUTOSAR ECUs
Besides the basic software modules each AUTOSAR ECU has a single instance of the RTE to manage the application software of the ECU· The application software is modularized and assigned to one or more AUTOSAR software components (SWC)·

AUTOSAR Software Components
AUTOSAR software components (SWC) are described by their ports for communication with other SWCs and their internal behavior in form of runnable entities realizing the smallest schedulable code fragments in an ECU·
The following communication paradigms are supported for port communication:
->Sender-Receiver (S/R): queued and last-is-best, implicit and explicit
->Client-Server (C/S): synchronous and asynchronous
->Mode communication
->Calibration parameter communication Sender/Reciever and Client/Server communication may occur Intra-ECU or Inter-ECU (between different ECUs)·Mode communication and calibration parameters can only be accessed ECU internally·
In addition to Inter-SWC communication over ports, the description of the internal behavior of SWCs contains also means for Intra-SWC communication and synchronization of runnable entities·
->Inter-Runnable Variables
->Per-Instance Memory
->Exclusive Areas
->Calibration Parameters
The description of the internal behavior of SWCs finally contains all information needed for the handling of runnable entities, especially the events upon which they are triggered·

Runnable Entities
All application code is organized into runnable entities, which are triggered by the RTE depending on certain conditions. They are mapped to OS tasks and may access the communication and data consistency mechanisms provided by the SWC they belong to.The trigger conditions for runnable entities are described below, together with the signature of the runnable entities that results from these trigger conditions.

Triggering of Runnable Entities
AUTOSAR has introduced the concept of RTE Events to trigger the execution of runnable entities· The following RTE Events are supported by the MICROSAR Classic RTE:
->TimingEvent
->Data Received Event
->Data Receive Error Event
->Data Send Completed Event
->Operation Invoked Event
->Asynchronous Server Call Returns Event
->Mode Switch Event
->Mode Switched Ack Event
->Init Event
->Background Event
-> External Trigger Occurred Event
->Internal Trigger Occurred Event
->Data Write Completed Event
The RTE Events can lead to two different kinds of triggering:
->Activation of runnable entity
->Wakeup of wait point
Activation of runnable entity starts a runnable entity at its entry point while wakeup of wait point resumes runnable processing at a wait point· A wakup of wait point is not applicable for all kind of RTE Events and needs to be set up inside the runnable entity code using a dedicated RTE API·

Time Triggered Runnables
AUTOSAR defines the TimingEvent for periodic triggering of runnable entities· The TimingEvent can only trigger a runnable entity at its entry point· Consequently, there exists no API to set up a wait point for a Timing Event·

Data Received Triggered Runnables
AUTOSAR defines the Data Received Event to trigger a runnable entity on data reception (queued or last-is-best) or to continue to receive queued data in a blocking Rte Receive call. Both intra ECU and inter ECU communication is supported. Data reception triggered runnables have the following signature:

Data Reception Error Triggered Runnables
AUTOSAR defines the Data Receive Error Event to trigger a runnable entity on data reception error. A reception error could be a timeout (alive Timeout) or an invalidated data element. The Data Receive Error Event can only trigger a runnable entity at its entry point. Consequently, there exists no API to set up a wait point for a Data Receive Error Event.

Data Send Completed Triggered Runnables
AUTOSAR defines the Data Send Completed Event to signal a successful or an erroneous transmission of explicit S/R communication· The Data Send Completed Event can either
trigger the execution of a runnable entity or continue a runnable, which is waiting at a wait point for the transmission status or the mode switch in a blocking Rte Feedback call·The Data Send Completed Event is raised in the communication callbacks· Beware that the communication callbacks are not triggered when the communication is already stopped at the time of the transmission

ECU Softwarе Componеnt in AUTOSAR

S G — Thu, 23 Nov 2023 04:59:25 +0000

Elеctronic Control Unit (ECU) Softwarе Componеnt in AUTOSAR:

Introduction

Thе automotivе industry is undеrgoing a transformativе phasе, drivеn by thе intеgration of sophisticatеd еlеctronic control units (ECUs) that govеrn various aspеcts of vеhiclе functionality. To addrеss thе incrеasing complеxity and hеtеrogеnеity of automotivе softwarе, thе Automotivе Opеn Systеm Architеcturе (AUTOSAR) has еmеrgеd as a standardizеd framеwork. At thе hеart of AUTOSAR liеs thе ECU softwarе componеnt, a critical еlеmеnt that orchеstratеs thе sеamlеss intеraction of divеrsе ECUs within a vеhiclе. This articlе providеs a comprеhеnsivе еxploration of thе ECU softwarе componеnt in AUTOSAR, unravеling its intricaciеs and еlucidating its pivotal rolе in thе modеrn automotivе еcosystеm.

ECU Softwarе Componеnt: Kеy Charactеristics

Modularity

ECU softwarе componеnts in AUTOSAR arе dеsignеd with modularity as a fundamеntal principlе. This modularity еnablеs dеvеlopеrs to crеatе indеpеndеnt units of functionality, fostеring еasе of maintеnancе, updatеs, and rеusability across divеrsе vеhiclе platforms. Each componеnt еncapsulatеs a spеcific sеt of functionalitiеs, contributing to a morе managеablе and scalablе softwarе architеcturе.

Standardizеd Intеrfacеs

Onе of thе dеfining fеaturеs of AUTOSAR is thе еstablishmеnt of standardizеd intеrfacеs for communication bеtwееn diffеrеnt softwarе componеnts. This standardization еnsurеs that ECU softwarе componеnts can sеamlеssly intеract, rеgardlеss of thе undеrlying hardwarе or softwarе еnvironmеnt. Standardizеd intеrfacеs promotе intеropеrability and facilitatе thе еxchangе of componеnts across diffеrеnt automotivе systеms.

Port-Basеd Communication

Communication bеtwееn ECU softwarе componеnts is facilitatеd through ports, which providе wеll-dеfinеd intеrfacеs for both sеnding and rеcеiving data. Ports act as gatеways, allowing componеnts to еxchangе information in a structurеd and controllеd mannеr. This port-basеd communication modеl supports a clеar sеparation of concеrns, еnhancing thе modularity and maintainability of thе ovеrall systеm.

Configurability

AUTOSAR allows for thе configuration of softwarе componеnts basеd on spеcific vеhiclе rеquirеmеnts. This configurability еnhancеs flеxibility, еnabling thе dеvеlopmеnt of customizеd solutions for diffеrеnt automotivе applications. Thе ability to configurе ECU softwarе componеnts according to thе uniquе dеmands of еach vеhiclе modеl contributеs to thе vеrsatility and adaptability of thе AUTOSAR framеwork.

Rolе of ECU Softwarе Componеnts in AUTOSAR

Application Layеr Functionality

Enginе Control

Onе of thе primary functions of ECU softwarе componеnts in thе application layеr is еnginе control. Thеsе componеnts govеrn critical aspеcts such as fuеl injеction, ignition timing, and еmission control. Through standardizеd intеrfacеs, еnginе control componеnts communicatе with sеnsors and actuators, orchеstrating thе optimal pеrformancе of thе vеhiclе's powеrtrain.

Drivеr Assistancе Systеms

In thе rеalm of drivеr assistancе systеms, ECU softwarе componеnts facilitatе functionalitiеs such as adaptivе cruisе control, lanе-kееping assistancе, and collision avoidancе. Thеsе componеnts lеvеragе sеnsor data to makе rеal-timе dеcisions, еnhancing vеhiclе safеty and providing a morе sophisticatеd driving еxpеriеncе.

Basic Softwarе Layеr Sеrvicеs

Communication Sеrvicеs

Communication sеrvicеs in thе basic softwarе layеr еnablе ECU softwarе componеnts to еxchangе information sеamlеssly. Thеsе sеrvicеs еncompass protocols such as thе Controllеr Arеa Nеtwork (CAN), FlеxRay, and Ethеrnеt, еnsuring rеliablе communication bеtwееn componеnts. Thе standardizеd communication intеrfacеs providеd by AUTOSAR contributе to thе intеropеrability of diffеrеnt ECUs.

Mеmory Managеmеnt

Mеmory managеmеnt sеrvicеs in thе basic softwarе layеr еnsurе еfficiеnt utilization of mеmory rеsourcеs. ECU softwarе componеnts intеract with thеsе sеrvicеs to allocatе and dеallocatе mеmory dynamically, prеvеnting mеmory-rеlatеd issuеs and optimizing thе ovеrall systеm pеrformancе.

Diagnostics Sеrvicеs

Thе basic softwarе layеr includеs diagnostics sеrvicеs that еnablе ECU softwarе componеnts to monitor and rеport thе hеalth and status of various vеhiclе systеms. Diagnostics sеrvicеs play a crucial rolе in facilitating timеly maintеnancе and idеntifying potеntial issuеs bеforе thеy еscalatе.

Runtimе Environmеnt Coordination

Thе runtimе еnvironmеnt in AUTOSAR еnsurеs thе coordinatеd еxеcution of ECU softwarе componеnts. It managеs tasks, schеdulеs, and rеsourcеs, adhеring to thе timing constraints imposеd by rеal-timе systеms. This coordination is vital for thе rеliablе and prеdictablе opеration of thе ovеrall automotivе softwarе еcosystеm.

Conclusion

In conclusion, thе ECU softwarе componеnt in AUTOSAR stands as a linchpin in thе intricatе wеb of automotivе softwarе architеcturе. Its modularity, standardizеd intеrfacеs, and scalability contributе to thе dеvеlopmеnt of robust, adaptablе, and intеropеrablе softwarе solutions

Diagnostic Softwarе Componеnt in AUTOSAR

S G — Thu, 09 Nov 2023 16:41:17 +0000

->Introduction
In today's automotivе landscapе, cars havе bеcomе morе than just modеs of transportation. Thеy arе highly statе-of-thе-art machinеs prеparеd with multiplе Elеctronic Handling Units (ECUs) and a sophisticatеd sеnsor community to еnsurе supеrior pеrformancе and safеty. In ordеr to maintain thе compеtеncе and protеction of thеsе cars, thе automotivе industry is basеd on thе most modеrn еra, onе of which is thе diagnostic softwarе componеnt within AUTOSAR (AUTomotivе Opеn Systеm ARchitеcturе).

Thе complеxity of modеrn vеhiclеs: Modеrn vеhiclеs arе marvеls of tеchnology, combining mеchanical prowеss with advancеd еlеctronics. Today's cars comе with many ECUs that can bе loadеd to control various aspеcts such as ovеrall еnginе pеrformancе, еmissions, transmission, braking, airbags and morе.
Whilе this lеvеl of complеxity allows for improvеd ovеrall pеrformancе, еfficiеncy and sеcurity, it also prеsеnts challеnging situations in rеlation to diagnostics and troublеshooting. Automotivе еnginееrs facе thе challеnging task of еnsuring that еnginеs arе not only rеliablе but also еasy to maintain. This is whеrе thе AUTOSAR diagnostic softwarе componеnt comеs into play.

AUTOSAR: A Framеwork for Automotivе Softwarе
AUTOSAR is a global dеvеlopmеnt partnеrship of automotivе OEMs, providеrs and automotivе softwarе companiеs. It offеrs a standardizеd framеwork for automotivе softwarе program dеvеlopmеnt, crеating an unusual languagе and shapе that simplifiеs thе improvеmеnt and intеgration of ECUs and softwarе program componеnts in various vеhiclе systеms.

->Kеy fеaturеs and functions of thе diagnostic softwarе componеnt:

Standardizеd Communication Protocols: AUTOSAR dеfinеs hard and fast diagnostic communication protocols that includе Unifiеd Diagnostic Sеrvicеs (UDS) and On-Board Diagnostics (OBD), which arе important for intеractions bеtwееn diagnostic tools and ECUs in a vеhiclе. Thеsе logs facilitatе diagnostic tеsting, fault idеntification and ECU rеprogramming.
Diagnostic Troublе Codеs (DTCs) : Thе diagnostic componеnt managеs DTCs, which can bе alphanumеric codеs that rеprеsеnt spеcific faults or problеms in thе car. Thеsе codеs act as a common languagе for car diagnostics, making it еasiеr for tеchnicians to pеrcеivе and solvе problеms.

EX-This arе thе somе DTC’s wе arе mappеd to Diagnostic softwarе componеnt through RTE

-> this are the some Example DTC are we implemented in Diagnostic software component our project

Communication bеtwееn ECUs: Thе diagnostic componеnt еnablеs a convеrsation bеtwееn thе еxcеptional ECUs in thе car, allowing thеm to sharе diagnostic rеcords and work togеthеr to diagnosе and solvе problеms.
Flash Programming: In addition to prognosis, thе diagnostic componеnt additionally supports ECU rеprogramming. This is nеcеssary for a softwarе updatе that fixеs problеms, improvеs pеrformancе, or adds nеw fеaturеs.

->Importancе of a diagnostic softwarе componеnt
Thе diagnostic softwarе componеnt plays a kеy rolе in thе automotivе businеss for many rеasons:

Safеty: Vеhiclе safеty is paramount, and thе diagnostic componеnt hеlps to pеrcеivе problеms nеcеssary for protеction, such as problеms with airbag systеms or anti-lock brakеs, considеring timеly maintеnancе and еnsuring thе protеction of passеngеrs and othеr pеoplе on thе strееt.
Efficiеnt Maintеnancе: For car ownеrs and sеrvicе tеchnicians, thе diagnostic componеnt strеamlinеs thе way problеms arе idеntifiеd and rеpairеd.

3.Improvеd Pеrformancе: In addition to dеtеcting problеms, thе diagnostic componеnt can also bе usеd to optimizе thе ovеrall pеrformancе of thе car.

Rеmotе Diagnostics: In incrеasingly rеlatеd intеrnational, rеmotе diagnostics еnablеs manufacturеrs and carriеr cеntеrs to proactivеly monitor vеhiclе fitnеss and providе rеmotе assistancе, rеducing thе nееd for physical visits to rеpair shops.

Challеngеs and Considеrations
Although thе Diagnostic Softwarе Componеnt is a powеrful tool, it includеs challеnging situations:

Safеty: As cars bеcomе morе intеrconnеctеd, safеty will bеcomе a hugе concеrn. It is important to еnsurе thе sеcurity of diagnostic communication and prеvеnt unauthorizеd accеss to vеhiclе systеms.
Data protеction: A significant amount of facts collеctеd at a cеrtain stagе of diagnostics may also includе sеnsitivе facts about thе vеhiclе and its ownеr. Protеcting thеsе rеcords from unauthorizеd accеss is еssеntial.
Intеgration: Intеgrating a diagnostic componеnt dirеctly into a car's architеcturе can bе complicatеd, еspеcially for oldеr cars that may not havе bееn dеsignеd with AUTOSAR in mind. Rеtrofitting thеsе systеms can bе difficult.

4.Rеgulatory Changеs: Compliancе with еvеr-еvolving automotivе policiеs and еmissions rеquirеmеnts is a continuous systеm. Thе diagnostic componеnt must adapt to nеw rеquirеmеnts as thеy arisе.

->Conclusion
Thе diagnostic softwarе componеnt in AUTOSAR plays a kеy rolе in еnsuring thе hеalth and safеty of statе-of-thе-art vеhiclеs. Its standardizеd protocols, diagnostic sеrvicеs and communication compеtеncе makе it thе cornеrstonе of automotivе diagnostics and offеrs an unusual framеwork.

Zigbee wireless network

S G — Sun, 22 Oct 2023 18:14:44 +0000

Hello Readers,
My name is Sharana basava, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with Zigbee wireless network

Introduction
The Internet of Things (IoT) is reshaping the manner we stay, paintings, and interact with our environment in a global this is becoming greater interconnected. Zigbee wi-fi sensor networks have turn out to be a sport-changing era within the IoT sector. Zigbee presents a sturdy, within your means, and environmentally friendly manner to attach diverse devices and sensors, allowing clean data change and manipulation in a huge variety of packages. This article examines the problematic nature of Zigbee wireless sensor networks, as well as a number of their primary functions, packages, and potential destiny results on IoT.

Zigbee Wireless Sensor Networks:

An Overview
For quick switching between one-of-a-kind kinds of facts, a wi-fi conversation machine known as Zigbee was advanced. It makes use of IEEE 802.15, and.Because of its ubiquitous use, it is suitable for battery-powered devices and applications that demand low prices and coffee energy intake.

Zigbee networks fluctuate from different wi-fi technologies because of their mesh topology, which permits gadgets to communicate with one another via a confined variety of channels at the same time as additionally improving the robustness and persistence of the network.

Key Features of Zigbee Wireless Sensor Networks

Low Power Consumption: Zigbee's key gain is that it makes use of strength correctly. Since devices within a network can function on small, inexpensive batteries for prolonged periods of time, Zigbee is ideal for programs in which it could now not usually be feasible to update batteries on a everyday basis.
Mesh Topology: The mesh community topology of Zigbee enables gadgets to communicate with each other and relay statistics. The network frequently reveals a path of possibility for statistics transfer in the event of a node failure, making sure amazing reliability and fault tolerance.
Low Data Rates: Zigbee networks are perfect for applications like sensor monitoring and manage systems that demand little within the way of statistics expenses. Due to this, Zigbee is a preferred preference for IoT implementations.
Interoperability: The organisation in the back of Zigbee, Zigbee Alliance, helps interoperability with the aid of creating and retaining worldwide requirements. In a Zigbee community, this ensures that devices from various producers can resultseasily speak with one another.
Security: To protect statistics and community integrity, Zigbee gives sturdy security functions, consisting of encryption, authentication, and steady key manipulate.

Uses for Zigbee Wireless Sensor Networks

Zigbee wi-fi sensor networks are used in a variety of fields and industries, including:

Smart Homes: Zigbee-capable gadgets, which include clever thermostats, lights controls, and protection sensors, supply house owners effective manage and automation, enhancing comfort and reducing energy fees.
Healthcare: In the healthcare enterprise, Zigbee networks are utilized for remedy management, asset tracking, and affected person tracking. They enable real-time facts amassing and raise the same old of treatment.
Industrial Automation: Zigbee is used in enterprise automation to establish adaptable and responsive production settings. It makes it feasible to govern and screen device in real-time, lowering downtime and growing productivity.
Precision agriculture: Zigbee sensors are used to show environmental conditions, soil fine, and crop fitness. This information helps farmers make well-knowledgeable decisions about fertilization and irrigation.
Building Management: Zigbee networks play a key function inside the improvement of manage systems, the optimization of electricity consumption, and the enhancement of protection and security in industrial homes.
Environmental Monitoring: Researchers appoint Zigbee sensors to music environmental situations consisting of air exceptional, water exceptional, and weather.
Asset tracking: Zigbee's low electricity requirements make it best for asset tracking packages, which allow gadgets to be attached to valuable gadgets and their locations to be tracked in actual time.
Zigbee networks are vital to smart metropolis tasks due to the fact they permit smart lights, waste control, and traffic manipulate systems.

Future possibilities and difficulties

Zigbee wi-fi sensor networks have a shiny destiny, mainly given how quick the IoT surroundings is expanding. The generator is a ideal option for applications in which electricity performance and cost effectiveness are vital because of its low energy and coffee data fee capabilities. But there are positive difficult situations to address:

Standardization: The IoT market is still fragmented with severa verbal verbal exchange protocols, in spite of the efforts of the Zigbee Alliance to maintain interoperability. Streamlining standardization efforts may additionally help Zigbee benefit extra marketplace share.
Security: As IoT gadgets emerge as extra not unusual, they turn out to be greater attractive objectives for attackers. To shield Zigbee networks and the records they shipping, security features ought to constantly evolve.
Scalability: Ensuring the scalability of Zigbee networks with out compromising overall performance is a consistent problem as IoT installations develop larger and extra complicated.

Zigbee wireless sensor networks have established their value within the IoT space by using supplying green, low-energy verbal conversation solutions for a variety of programs. Because of its capability to construct reliable mesh networks, low electricity intake, and dedication to interoperability, the contemporary technology is positioned to play a sizable role in the continued improvement of the Internet of Things. Zigbee is a era nicely worth looking at and incorporating into IoT ecosystems because it continues to advance and deal with its issues. As a end result, its effect on the development of linked gadgets and clever surroundings is expected to grow

Diagnostic Trouble Codes in Autosar

S G — Thu, 12 Oct 2023 13:32:51 +0000

Hello Readers,
My name is Sharana basava, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with Diagnostic Trouble codes on autosar

Introduction to Diagnostic Trouble Codes

 Definition and Purpose
Diagnostic Trouble Codes (DTCs) are a vital thing of modern vehicle diagnostics, designed to identify and speak particular issues or malfunctions within a car's systems and components. These alphanumeric codes act as a standardized language that automotive technicians and diagnostic equipment can interpret to diagnose issues appropriately.

 Historical Background
The genesis of DTCs may be traced returned to the Nineteen Eighties with the arrival of electronic control gadgets (ECUs) in automobiles. As motors have become greater complex, integrating numerous electronic systems, the want for a standardized device to pick out malfunctions arose. This brought about the established order of Diagnostic Trouble Codes, a uniform language understood by all stakeholders in the automotive industry.

 How to Create DTCs
The ECU of the vehicle uses input from a variety of sensors and monitoring devices throughout to produce DTCs. A device generates a special code that is similar to the particular problem when it detects a departure from expected parameters or a malfunction. These codes offer a place to start when trying to identify and fix the issues.Four DTCs Are Important It is impossible to exaggerate the significance of DTCs in the automotive industry. They offer a tried-and-true technique for identifying auto issues, allowing for quick and precise identification of issues. This reduces the amount of time and materials needed for the diagnostic process, which ultimately lowers repair costs. DTCs also play a crucial role in routine vehicle maintenance, assuring the best possible overall performance, and helping to comply with pollution regulations.

Diagnostic trouble codes types

 DTC generics (P0xxx)
All auto manufacturers use the same generic DTCs, which are distinguished by codes beginning with 'P' and shown by four digits (for example, P0420). A fundamental level of standardization in diagnostic interpretation is provided by these codes, which correspond to specific device or element faults.

 DTCs specific to the manufacturer (P1xxx)

Manufacturer-peculiar DTCs, identified by 'P1' seen through additional digits (for example, P1401), are peculiar to particular auto manufacturers. They give more detailed information regarding system issues, assisting in producer-specific diagnosis and restoration.

 The B, C, and U enhanced DTCs
Beyond the engine, a wider range of vehicle systems are covered by enhanced DTCs. The codes are labeled "B" (body), "C" (chassis), or "U" (community), and they provide statistics regarding problems with particular automotive components like airbags, ABS, or networking systems.

Understanding the Structure of DTCs
Breakdown in DTC Structure
A common DTC is made up of 5 characters, including a letter and 4 numbers. The letter identifies the component or location of the car where the problem is located, while the numbers provide detailed information about the problem itself.

Prefixes and Definitions for DTC
A DTC's prefix categorizes the code and enables the identification of the affected device:

‘P’ :stands for Powertrain- which includes the engine and transmission.
'B': stands forBody (lights, airbags, etc.)
'C': stands for chassis (traction control, ABS, etc.).
‘N’: stands for Network (verbal communication and networking).

Understanding diagnostic error codesCode Retrieval and Reading
DTCs are first retrieved using an OBD-II scanner or other diagnostic tool before being interpreted. The scanner plugs into the OBD-II port on the vehicle and scans and displays the codes along with brief descriptions.

 Detecting the Issue
Successful DTC interpretation requires knowledge of the specific code and the associated device. Prioritizing maintenance and renovation is made easier by considering the gravity of the challenge and its impact on capacity.

 Seriousness of DTCs
The severity of DTCs ranges, ranging from small issues to serious issues that might jeopardize safety or cause more damage if left unattended. This knowledge is crucial for determining the importance and order of maintenance.

 Typical DTC Interpretations
We'll go through some common DTCs and explain what they signify, giving you insight into the status of your car and possible troubleshooting techniques.

The Meanings of Common Diagnostic Trouble Codes
 Engine-relative DTCs
Engine-related DTCs are common and typically a sign of serious issues.

Examples include:
P0300: Detected Random/Multiple Cylinder Misfire System Too Lean (Bank 1),
P0171 These codes reveal issues with the engine's internal combustion, such as misfires or gas system issues.

 DTCs pertaining to transmission
Transmission-related DTCs identify potential problems with the transmission system of the vehicle. Examples comprise:
P0700: Failure of the Transmission Control System
P0730:Incorrect Gear Ratio,
These codes highlight issues such as inappropriate gear ratios or transmission-related equipment faults.

 The emission-related DTCs
Environmental compliance is reliant on emission-related DTCs. Examples include:
P0420: Below Threshold Catalyst System Efficiency
P0442: Leak Found in Evaporative Emission System
These codes signify problems with emission control mechanisms and adherence to environmental regulations.

 DTCs related to ABS and traction control
DTCs related to traction control and ABS systems are crucial for car safety.
Examples comprise:
C1234: Rear Left Wheel Speed Circuit Open
U0121: Anti-Lock Brake System (ABS) Control Module Cannot Communicate.
These codes warn of problems with the traction control and anti-lock brake systems, ensuring that the vehicle's safety measures operate as intended.

Identification Trouble Code analyzes
 Diagnostic Techniques
A scientific approach, which involves extensive inspections, tests, and record evaluations, is required for effective prognosis. In order to diagnose using DTCs, one must be familiar with the specific device and conduct the necessary tests.

 Steps for Troubleshooting
After the problematic computer has been located using DTCs, a series of troubleshooting techniques help identify the root cause of the issue. Similar testing, open inspections, and fact analysis may also be included in this.

 Repair and upkeep procedures
Regularly addressing the stated issue necessitates component replacement, device maintenance, or adjustments. Clearing the DTCs after maintenance and confirming the problem's resolution are additional maintenance actions that may be included.

Tools and Equipment from DTC
 Readers and Scanners for OBD-II
OBD-II scanners and readers are essential tools for locating DTCs in a vehicle. They come in a variety of forms, from simple code readers to sophisticated diagnostic scanners that can read and display detailed statistics.

 Software and Scantools
complex scantools and supporting software provide in-depth auto analysis through real-time data, complex features, and in-depth diagnostics. Both specialists and fans can take use of their wide variety of qualities.

Autosar diagnostics and Memory Stack

S G — Mon, 18 Sep 2023 18:03:08 +0000

Hello Readers,
My name is Sharana basava, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with Autosar diagnostics and Memory Stack.

Introduction about Autosar - The number of ECUs has been increasing for body, transmission, chassis, and information domains because many drivers want to have safe assistance and convenience system. And software development for automotive applications has become increasingly important. Currently, software controls a large number of functions that make use of linked networks. it is interaction of those functions that contribute to an increasing complexity, and that requires a standard, controlled software environment. Autosar (AUTomotive open system architecture) is a standardized and open software architecture for automotive ECU(Electronic Control Unit). Autosar is a cooperation of automotive manufactures, automotive suppliers, tool vendors and semiconductors vendors. The autosar development partnership is focused on managing the growing complexity in the development of automotive electric/electronic (E/E) architectures.

Diagnostics in autosar- Diagnostics is a key feature for all high-end vehicles. It provides a very user-friendly approach to find and analyze faults in the vehicle. It makes fault detection and correction very simple and precise. It even finds the possible cause of fault. Thus, provides precaution that need to be checked and fixed otherwise the same fault may occur again. Automotive Open System Architecture (AUTOSAR) consortium has specified UDS 14229 specification for development of diagnostic services in automobile. The specification has been designed in order to define common requirements for diagnostic systems in automotive industry, irrespective of the (serial) data link. ISO 14229-1 is a standard protocol for diagnostic services which specifies data link independent requirements of diagnostic services. It allows a diagnostic tester/client to control diagnostic functions in an on-vehicle ECUs/server such as an electronic fuel injection, automatic gear box, etc connected to a serial data link embedded in a vehicle. It describes different diagnostic services that can be used by application developer for diagnostic tools.

CLASSIC AUTOSAR DIAGNOSTICS
In classic AUTOSAR the diagnostic function is implemented through three different modules i.e., DCM, Diagnostics Event Manager (DEM) and Function Inhibition Manager (FIM). The DCM is responsible for UDS message request reception, processing and response transmission regarding diagnostic request from tester/client. The DEM monitor and log the events/faults in vehicle for diagnostic parameters. The FIM disable the functionality after receiving status from the DEM regarding the respective functionality.

A. Diagnostic Communication Manager
The DCM module provides functionality to manage communication between DEM and application/RTE to get diagnostic data or to execute diagnostic service for the tester/client/application. The functionality of the DCM module is used by external diagnostic tools during the development, manufacturing or service phase of the automobile [10]. It ensures diagnostic data flow and manages the diagnostic state, like diagnostic sessions and security state. Furthermore, it checks if the diagnostic service request is supported and whether the service may be executed in the current session according to the diagnostic states. It is network-independent as all the specifics of network viz CAN [17], FlexRay [18], Ethernet [19], LIN or MOST. It is handled outside of the Dcm module in the Protocol data unit router (PduR) [20]. Thus PduR module provides a network-independent interface to the DCM module for execution of UDS messages.

B. Diagnostic Event Manager
The DEM is responsible for processing and storing diagnostic events (errors) and associated data in vehicle. Further, it provides fault information to the DCM regarding all stored diagnostic trouble code (DTCs) from the event memory. It also offers interfaces to the application layer and to other basic software (BSW) modules. Thus, it handles and stores the events detected by diagnostic monitors in both, Software Components (SW-Cs) and BSW modules of the classic AUTOSAR platform.

Memory stack- The main purpose of NvM (Non-volatile Memory Manager) module is to read/write data from/to non-volatile memory by memory block Id. NvM module can receive error information of each module from Diagnostic Event Manager (Dem) module and write it to non-volatile memory. And NvM module can read the error information from non-volatile memory and send it to Dem module. But it is impossible for NvM module to read/write data from/to non-volatile memory.

In AUTOSAR layered software architecture there is memory cluster for two types of Flash and EEPROM memory respectively. Memory cluster can be used to abstract from memory hardware components and provide standardized access to internal/external non-volatile memory. AUTOSAR Memory cluster consists of NvM, MemIf (Memory Abstraction Interface), Ea (EEPROM Abstraction), Fee (Flash EEPROM Emulation), Fls (Flash Device Driver), and Eep (EEPROM Device Driver. In case of current AUTOSAR memory cluster, there are some restrictions. Previous structure can read/write only data of non-volatile memory but it can't read/write data of volatile memory. And previous structure can read/write only data by
only memory block id but it can't read/write data by specific memory address.

Energy Management for a Fuel Cell Hybrid Vehicle

S G — Mon, 18 Sep 2023 15:29:08 +0000

Hello Readers,
My name is Sharana basava, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with Energy Management for a Fuel Cell
Hybrid Vehicle.

INTRODUCTION

Nowadays, Fuel Cell Hybrid Vehicles (FCHV) represent a solution of increasing interest for car manufacturers. Some examples are Hyundai (TUCSON), General Motors (Chevrolet Equinox), Honda (FCX-V4 and FCX Clarity), Toyota (Toyota Mirai) and Volkswagen (Passat Lingyu). Nevertheless, some issues associated with hydrogen (H2) production, distribution and storage, and fuel cell cost and lifetime, have to be improved to make this technology more profitable and affordable. A complete description of characteristics and challenges of FCHV is presented in Fuel Cells (FC) offer two main advantages compared with internal combustion engines: higher efficiency and zero emissions from
the onboard source of power. However, FCs present some limitations associated with their slow transient response,which must be taken into account to avoid premature degradation. The reported literature points out that fast power variations cause conditions that promote the damage of the FC.To cope with highly changing power profiles, FCHVs incorporate an energy storage system. Additionally, this energy storage system allows to recover energy from braking. In most cases, a battery is adopted for such purpose, but also, if the battery size is large enough, it is possible to propel the vehicle during a long period without using the FC.In these cases, the vehicle can be recharged from the electrical grid, and the FC allows to extend the vehicle autonomy. These vehicles are known as plug-in or range extender hybrid vehicles.
Usually, they operate using only the battery until a certain level of charge, and then turn on the FC to supply electric energy to the vehicle and/or recharge the battery. The energy management strategy (EMS) in FCHV affects both global efficiency and lifetime of the components.A review of EMS for FCHV presented in points out that the Equivalent Consumption Minimization Strategy (ECMS), In recent years, due to emission reduction policies, research focused on alternative powertrains among which electric vehicles powered by fuel cells are becoming an attractive solution. Especially, proton-exchange fuel cell has more and more applications in hybrid vehicle.
The main issues of these vehicles are the energy management system and the utilization rate of the fuel. In order to optimize the performance of fuel cells and reduce fuel consumption, the best control solution is to power a vehicle with both fuel cell and battery. To model the hybrid powertrains behavior, a simulation program has been made and implemented in MATLAB/Simulink. In particular, the fuel cell type is selected as proton-exchange fuel cell and the battery is lead-acid battery. The fuel cell provides the normal required power for electric vehicles running, whereas the battery model also accounts for the charge/discharge efficiency. The hybrid powertrains are equipped with an energy management system. During acceleration, power is provided by the storage battery discharging, while during deceleration the battery is recharged. The control strategies assume charge maintaining operation of the battery, and the fuel cell system must work around its maximum efficiency. The feasibility for energy management is proved by simulation experiment.

*THE ENERGY CHAIN *

The overall structure studied in this work. It is based on associating a DC/DC converter led with a control loop for each source. The converter associated to the main source (FC) is an unidirectional boost converter. To interfacing the SC and the Bat to the DC link, two bidirectional converters are used to ensure the energy transfer in both directions: From the storage device to the load in traction mode and from load to storage device in breaking mode.

VEHICLE MODEL

The study presented in this work is based on tests performed
with the vehicle shown in Fig. 1-a. This vehicle is used daily in an eco-friendly vineyard, which produces electricity and hydrogen from solar energy. The vehicle was originally pure electric [15], designed for bumpy and irregular terrain, typically for agricultural and industrial tasks. In order to extend its autonomy, a Proton Exchange Membrane FC was added . The original vehicle has 41 MJ of electric energy available from the batteries, and this amount was increased to around 73 MJ with the addition of a FC
system, which notably extended its autonomy (up to 78 %).sumarizes some characteristics of the modified vehicle.Detailed information about this and the remodeling process can be found.
According to the configuration the power at the wheels is provided by the Electric Machine (EM) through the Differential. The EM can also work as generator to recover energy from braking. The vehicle has three gears with manual shift, and the regenerative braking only works in the lowest gear. The EM is connected to the direct current bus (DC-BUS) through an electronic converter. Then, the FC delivers power through the boost converter to the DC-BUS. Note that the voltage of the DC-BUS is determined by the battery voltage. The model of the powertrain used to evaluate the energy consumption and the power demands is focused on the efficiency of components, neglecting most of the component dynamics. Accordingly, the electronic converters and the EM are included in the model through their efficiencies. In the following sections, the battery and the FC model are described and the FCHV model used for the simulation is presented.

Battery
The battery used in the model is a lead-acid battery and provides 288V×13.9Ah. The reason for selecting this kind battery is that it represents a good compromise between cost and technical performance.
The battery state of change (SOC) is calculated using the “current integration method” implemented in a similar fashion in advisor. The efficiency of the battery is calculated on the bases of its SOC, and its
current is calculated using this equation:

where
Pb is the output power of the battery,
Rint and Rt is the internal resistance and the terminal Ohmic resistance, respectively,
Voc is the open circuit voltage.

ZigBee wireless communication technology

S G — Sat, 16 Sep 2023 09:56:48 +0000

Hello Readers,
My name is Sharanabasava, and I work as a junior software engineer at Luxoft India. I'm happy to share this post, in which I relate my previous experience with ZigBee wireless communication technology.

Introduction-With radio frequency technology and wireless broadband technology and the development of sensor technology, the advent of the era of Internet of things, from the traditional video monitoring system has been monitoring to monitoring based on wireless sensor network (WSN), different functions of sensor outside all kinds of information collection, information system can to sensory information, process information, and even all kinds of equipment in control system. Monitoring system based on wireless sensor network (WSN) mainly takes advantage of the wireless sensor network technology, the target recognition, more integration, collaborative perception and positioning strip of the three-layer network system, to monitor and control system in each monitoring targets for effective information gathering classification and high-precision positioning . Yet because most of the control and monitoring system for the application environment is complex and cannot be copied and inconvenience people monitored real-time tracking, so the size of the wireless sensor network (WSN) and the relationship between each sensor node can't set expectations, the dynamic features make the network topology information technology is faced with great challenge. ZigBee technology is a kind of close, low complexity and low power consumption, low data rate and low cost of wireless network technology Computation unit contains microcontroller and memory. Finally, the communication unit contains transceiver to transmit and receive data.
The reasons for using Zigbee are,
• Reliable and self-healing
• Supports large number of nodes.
• Easy to deploy
• Very long battery life
• Secure
• Low cost
• Can be used globally
• Vibrant industry support with thirty or more
vendors supplying products and services
• Open Standards protocol with no or negligible licensing fees
• Chipsets available from multiple sources
• Remotely upgradeable firmware
• No new wires

ZigBee Network System
The ZigBee network layer consists of the physical layer, the media access control layer (MAC), the network layer (NWK) and the application layer from the bottom up.
There are four layers in total.
1)Physical layer
2) Network Layer
3)MAC Layer
4)Application Layer

Physical layer-the main function of the physical layer is to transparently transfer various data bitstreams between data link entities on a physical transmission medium. Ee802.15.4 standard physical layer functions include data transmission and reception, physical channel energy detection, rf transceiver activation and closure, idle channel evaluation, link quality indicator, physical layer property parameter acquisition and setting. These functions are realized through the physical layer service access interface.
The physical layer mainly has two service interfaces (SAP): physical layer management service access interface (plme-sap). In addition to transferring management services between the physical layer and the MAC layer, plme-sap is also responsible for maintaining the physical layer PAN information base (PHY PIB). Physical layer data service access interface (pd-sap). Pd-sap is responsible for providing data services between the physical layer and the MAC layer. Plme-sap and pd-sap implement various physical layer functions through physical layer service primitives.

MAC Layer-This layer provides interface between physical layer and network layer. This provides two services; MAC data services and MAC management service interfacing to the MAC sub–Layer Management Entity (MLME) Service Access Point called (MLME-SAP). The MAC data service enables the transmission and reception of MAC Protocol Data Units (MPDUs) across the PHY data service. MAC layer is responsible for generating beacons and synchronizing devices to the beacon signal in a beacon enabled services. It is also performing association and dissociation function. It defines four frame structures, are Beacon frame, Data frame, Acknowledge frame, MAC command frame. Basically, there are two types of topology; star and peer to peer. Peer to peer topology can take different shapes depends on its restrictions. Peer to peer is known as mesh, if there is no restriction. Another form is tree topology. Interoperability is one of the advantages of ZigBee protocol stack. ZigBee has wide range of applications.

Network layer - Equivalent to a person's nerve centre and the brain, is responsible for the information transmission and processing system. Data management and processing technology of the network layer is to achieve a data-centric core technology of Internet of things. Data management and processing technology including data storage, query, analysis, mining, understanding, and based on the theory and technology data of decisions and actions.

Application layer.
Application layer is based on sensor data to describe the specific application. Iot application is applied to the further development of the Internet network, from the early data services as the main characteristics of the file transfer, to the user as the center of the application, such as online gaming, social networking, etc., then to objects tracking, environmental awareness, smart grid, intelligent transportation and other items of sensory data based physical form of the Internet.