DEV Community: santoshchikkur

significance of Smoke Testing

santoshchikkur — Wed, 28 Feb 2024 05:57:20 +0000

Hello Readers,
My name is Santosha S Chikkur, 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 learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in "significance of Smoke Testing".

Introduction

Smoke testing is a software program trying out manner that determines whether or not the software program version in use is stable or no longer. Smoke trying out offers the QA crew approval to preserve checking out the software. It consists of minimum tests that can be accomplished in each launch to check the functionality of the software program. Smoke testing is likewise referred to as "constructing Verification testing".

Simply positioned, the smoke testing approach makes sure that important capabilities work and that there are not any screens in the model being tested. This is a small and short regression check of the maximum vital features. This is an easy check that indicates that the product is prepared for testing. This allows determining if the layout is defective, making further checking out a waste of time and resources.

Image description

When can we do smoke checking out

Smoke checking out is performed every time a new software characteristic is advanced and integrated into a current continuation deployed in a QA/inference surroundings. This guarantees that every one of the crucial functions are working well or now not.

In this trying out method, the improvement team deploys the construct in QA. Subsets of check instances are taken and then testers execute the check instances in series. The QA group check the utility towards the important functionalities. These collection of assessments are designed to uncover set up mistakes. If those assessments bypass, the QA team maintains with purposeful exams.

Any failure shows that the machine ought to be again to the development team. When converting the shape, we do a smoke test to ensure stability.

What occurs if we don’t do Smoke trying out

If we do no longer smoke check at an early level, defects can appear at later stages, which can be pricey. And an error observed in later tiers can be boundaries in which it is able to have an effect on the e-book of consequences.

When and How Often Do We Need Smoke Testing?

Smoke trying out is a company father or mother of software program balance and guarantees that each new edition and launch takes a assured step earlier than similarly testing starts offevolved. Just as a pilot cautiously inspects an plane's important structures earlier than a flight, smoke trying out examines key software capabilities.

This short, 60-minute technique must come to be an fundamental part of the software development lifecycle, applied with every new build and release, even supposing it method a daily recurring. As the software program matures and stabilizes, automating smoke testing within a CI pipeline becomes a treasured asset.

Image description

Why do we do smoke testing?

Smoke testing performs an important function in software development as it guarantees the correctness of the gadget in initial stages. By this, we are able to shop check attempt. As a end result, As a end result, smoke exams bring the machine to the best nation. Once we're achieved with smoke checking out, we will just begin useful trying out.

All structural exposure limits are decided by using smoke take a look at. A smoke check is carried out after the model is released to QA. With the help of smoke trying out, maximum of the defects are diagnosed at preliminary tiers of software improvement. With smoke testing, we simplify the detection and correction of essential defects.

With smoke checking out, the QA group can discover insects within the functionality of the software that may have seemed inside the new code.
Smoke testing finds the predominant severity defects.

*Smoke testing cycle
*
Below drift chart shows how Smoke Testing is accomplished. Once the build is deployed in QA and, smoke exams are exceeded we continue for purposeful testing.If the smoke check fails, we forestall testing till the hassle with the structure is resolved.

Image description
**
How to Run Smoke Testing?**

Here's a step-by way of-step process on the way to run smoke trying out:

1.Collect check instances
Identify the main functions of the software program.
Prioritize test instances that cowl vital capabilities and vital workflows. Ensure check instances are clear, concise, and repeatable.

2.Prepare the Testing Environment
Create a take a look at surroundings that mirrors the manufacturing surroundings as near as feasible. Make positive the test surroundings has all of the important gear and sources. Make certain the check environment is clean and free of present issues.

3.Execute Smoke Test Cases
Run prepared smoke take a look at cases manually or the use of automatic equipment. Document the results of each check and notice any outcomes or issues determined. If necessary, take screenshots or display recordings for similarly evaluation.

**4.Analyze Results and Report Findings
**Review check outcomes to perceive failed checks or ability defects Categorize and prioritize troubles according to their severity and effect. Present your findings without a doubt and concisely to the development group.

5.Retest and Verify Fixes
Retest the affected areas after the improvement team has fixed the insects. Make certain that the fixes have solved the diagnosed issues without growing new problems. Update check documentation to mirror modifications and make certain consistency.

6.Continuously Improve Smoke Testing
Regularly evaluation and refine smoke checks to encompass evolving software program capabilities. Evaluate the effectiveness of smoke trying out practices and make important adjustments. Automate smoke trying out where possible to enhance performance and reduce take a look at time. Remember that smoke trying out is an iterative process that ought to be carried out frequently during the software program improvement lifecycle to make certain software stability and fine.

Conclusion

In this Article I have tried to explain about the Significance of smoke testing , Please let me know if any improvements needs to be done Thank you.

Exploring Flash Driver (FLS) Integration in AUTOSAR: Empowering Automotive Embedded Systems

santoshchikkur — Tue, 27 Feb 2024 13:49:25 +0000

***Introduction:*

In the intricate tapestry of modern automotive embedded systems, Flash Driver (FLS) integration within the AUTOSAR framework stands out as a cornerstone of reliability performance, and adaptability. The fusion of FLS technology with AUTOSAR standards revolutionizes how vehicles manage critical data storage and firmware updates, paving the way for enhanced functionality, efficiency, and safety on the road.

Understanding Flash Driver (FLS) in AUTOSAR:

Streak Driver (FLS) may be a principal component of car electronic control units (ECUs), dependable for meddling with non-volatile memory (NVM) gadgets such as Streak and Electrically Erasable Programmable Read-Only Memory (EEPROM). Inside the AUTOSAR design, FLS serves as the interface between the program components and the fundamental NVM equipment, encouraging consistent examination, composition, and deletion operations.

Benefits of FLS in AUTOSAR:

Reliable Data Storage:

FLS integration guarantees a solid capacity of basic information, counting calibration parameters, symptomatic inconvenience codes (DTCs) and setup settings. By following AUTOSAR benchmarks, FLS mitigates the chance of information debasement and guarantees information astuteness over different working conditions.

Efficient Firmware Updates:

AUTOSAR-compliant FLS empowers effective and secure firmware overhauls, commonly alluded to as over-the-air (OTA) overhauls. This capability is significant for sending computer program patches, including improvements and bug fixes remotely, without requiring physical get to the vehicle.

Fault Tolerance and Redundancy:

FLS implementation within AUTOSAR emphasizes fault tolerance and redundancy, minimizing the impact of NVM failures or errors. By employing robust error-handling mechanisms and redundancy strategies FLS enhances the resilience of automotive systems, especially in safety-critical applications.

**Scalability and Compatibility:

**The modular architecture of AUTOSAR and the standardized interfaces of FLS facilitate scalability and compatibility across different hardware platforms and vehicle models. This scalability allows automotive manufacturers to tailor FLS implementations to meet specific performance cost and footprint requirements.

Optimized Performance:

FLS optimization techniques, such as wear leveling and garbage collection, maximize the lifespan and performance of NVM devices. By intelligently managing data erasure and wear distribution FLS minimizes the risk of premature NVM failure and ensures consistent performance over the vehicle's lifecycle.

Challenges and Solutions:

In spite of the various benefits, joining FLS into AUTOSAR poses a few challenges, including compatibility issues execution overhead, and cybersecurity concerns. In any case, continuous standardization endeavors inside the car industry, coupled with headways in NVM innovation and computer program optimization strategies, are tending to these challenges viably.

Use Cases:

OTA Updates and Remote Diagnostics:

FLS-enabled AUTOSAR ECUs facilitate seamless OTA updates, allowing manufacturers to deploy software patches and security enhancements remotely. Furthermore FLS supports remote diagnostics, enabling real-time monitoring of vehicle health and performance metrics.

Data Logging and Telematics:

FLS integration is essential for data logging and telematics applications, where reliable storage and retrieval of sensor data are paramount. By leveraging FLS within the AUTOSAR framework vehicles can capture and transmit valuable telemetry data for fleet management, predictive maintenance, and performance analysis.

Bootloader and Boot Management:

FLS plays a crucial role in bootloader and boot management functions, ensuring the safe and reliable startup of automotive ECUs. AUTOSAR-compliant FLS implementations facilitate secure boot procedures cryptographic verification, and integrity checking to prevent unauthorized access and tampering.

Future Prospects:

As car-inserted frameworks proceed to advance, the integration of FLS inside the AUTOSAR system will stay instrumental in driving advancement and versatility. Rising patterns, such as jolt, independent driving and network, will encourage and emphasize the significance of FLS in empowering progressed highlights and functionalities in next-generation vehicles.

Conclusion:

The integration of Streak Driver (FLS) innovation inside the AUTOSAR system speaks to a noteworthy point of reference within the advancement of car-inserted frameworks. By leveraging FLS capabilities to guarantee solid information capacity, productive firmware upgrades, and blame resistance car producers can convey more secure, more dependable, and associated vehicles to meet the advancing requests of shoppers and administrative necessities alike.

Thanks for Reading.

Unveiling the Power of MCU in AUTOSAR: A Fusion of Innovation in Automotive Systems

santoshchikkur — Tue, 27 Feb 2024 13:27:30 +0000

Introduction:

Within the ever-evolving scene of car innovation, the integration of Microcontroller Units (MCUs) inside the AUTOSAR (Car Open Framework Design) system has risen as an urgent worldview. This cooperative energy of MCU and AUTOSAR brings forward a modern period of effectiveness, adaptability, and versatility in car frameworks, revolutionizing the way vehicles work, communicate, and adjust to energetic situations.

Understanding MCU in AUTOSAR:

Microcontroller Units (MCUs) are the electronic brains implanted in vehicles, capable of overseeing different capacities, from motor control to progressed driver help frameworks. AUTOSAR, on the other hand, is an open and standardized program engineering that encourages the improvement, integration, and upkeep of car programs. When these two powers combine, they make a vigorous establishment for building brilliantly interconnected car frameworks.

Benefits of MCU in AUTOSAR:

Enhanced Performance:
The integration of high-performance MCUs inside the AUTOSAR system permits for speedier and more effective preparation of complex calculations. This comes about in progress in general vehicle execution, responsiveness, and versatility to real-time driving conditions.

Scalability and Flexibility:
AUTOSAR's secluded design coupled with the flexibility of MCUs empowers versatility, permitting car producers to consistently coordinate extra highlights and functionalities. This versatility is significant for adjusting to the ever-changing requests of the car advertise.

Interoperability:

The standardized approach of AUTOSAR guarantees interoperability among different computer program components, whereas the MCU acts as the equipment spine. This interoperability rearranges the integration of assorted car applications, cultivating collaboration among diverse partners within the car biological system.

Reduced Development Time and Costs:
The utilization of AUTOSAR and MCU streamlines the advancement handle by giving a common stage for program plan and execution. This commonality decreases advancement time and costs, making it more doable for producers to improve and bring modern highlights to showcase rapidly.

Reliability and Safety:
Security is foremost within the car industry, and the combination of MCU and AUTOSAR improves unwavering quality through standardized interfacing and communication conventions. This standardized approach contributes to the advancement of vigorous and fail-safe car frameworks.

Challenges and Solutions:
Whereas the integration of MCU in AUTOSAR offers various focal points, it comes with its claim set of challenges. Guaranteeing compatibility over a wide run of equipment and computer program components, overseeing complexity, and tending to cybersecurity concerns are a few of the key challenges. In any case, nonstop collaboration inside the car industry, adherence to measures, and progressions in cybersecurity measures are tending to these challenges.

Use Cases:

Advanced Driver Assistance Systems (ADAS):
MCU in AUTOSAR plays a vital part in the improvement of ADAS, empowering highlights such as versatile voyage control, lane-keeping help, and programmed crisis braking. The tall computing control of MCUs improves the real-time handling required for these safety-critical applications.

Infotainment Systems:
The combination of MCU and AUTOSAR hoists the execution of infotainment frameworks, advertising a consistent and immersive client involvement. From in-car amusement to route and network, the coordinates approach guarantees unwavering quality and responsiveness.

Electric Vehicle (EV) Management:
Within the domain of electric vehicles, MCU in AUTOSAR contributes to productive battery administration, control conveyance, and overall system optimization. This can be vital for upgrading the extent, proficiency, and unwavering quality of electric vehicles.

Future Prospects:

As car innovation proceeds to advance, the collaboration between MCU and AUTOSAR is balanced to play a significant part in forming the long run of associated, independent, shared, and electric (CASE) vehicles. The continuous progressions in both equipment and computer program components will encourage improving the capabilities of MCU in AUTOSAR, driving advancement and introducing a modern time of clever and maintainable transportation.

Conclusion:

The integration of MCU inside the AUTOSAR system marks a noteworthy breakthrough within the car industry, opening a domain of conceivable outcomes for advancement and proficiency. As vehicles ended up progressively advancing, the collaboration between MCU and AUTOSAR guarantees that car frameworks can adjust, communicate, and perform consistently, giving a more secure, more associated, and agreeable driving involvement for clients around the world.

Thanks for Reading.

Electric and Hybrid Vehicle technology PART-2

santoshchikkur — Sun, 18 Feb 2024 14:33:33 +0000

ELECTRIC VEHICLE COMPONENTS

Motor
Controller
Charger
Dc/Dc Converter
Battery Management System
Instrumentation
Contactor(s)
Safety Equipment

Motors

Electric motors are the main source of power, for an Electric vehicle, which converts Electrical Energy into Mechanical Energy. There are mainly 2 types of Electric Motors used in EVs: DC Motors and AC Motors. The main components of DC motors are.

A set of field coils around the border of the engine that makes an attractive drive that gives torque.
A rotor or armature installed on the bearing.
A commutating device, which reverses the magnetic field and makes the armature turn.

AC Motors are similar to DC motors, but they don’t need any Commutating devices, since there is a continuous current reversal. Both AC and DC Motors have their advantages and disadvantages, so they are not superior to one another.

Electric Motor Comparison

AC Motor
1) Fail-safe design, Low initial torque, higher speed
2) Requires complicated electronics package
• AC speed control (similar to industrial)
• Inverter (convert DC to AC)
• High voltage (240-350 V)
• Bearings are the only mechanical maintenance item

DC series wound
1) Motors are available and inexpensive
2) 100% torque at 0 RPM
3) Controllers are very cheap compared to AC
4) No inverter stage is required
5) Lower voltage system (72-156 VDC)
6) Bearings and brushes are potential maintenance items.

A: shunt
B: series
C: compound
f= field coil

Controller

An engine controller could be a gadget or bunch of gadgets that serves to oversee in a few foreordained ways the execution of an electric engine. An engine controller might incorporate a manual or programmed implies for

Starting and stopping the motor
Selecting forward or reverse rotation
Selecting and regulating the speed,
Regulating or limiting the torque
Protecting against overloads and faults

Battery management system
There are three fundamental targets common to all Battery Administration Frameworks

• Secure the cells or the battery from harm
• Prolong the life of the battery
• Keep up the battery in a state in which it can fulfill the useful prerequisites of the application for which it was indicated.

Most electric vehicles use lithium-ion batteries. Lithium-ion batteries have higher vitality thickness, longer life span, and higher control thickness than most other viable batteries. Complicating variables incorporate security, solidness, warm breakdown, and fetched. Li-ion batteries ought to be utilized inside secure temperature and voltage ranges in arrange to function securely and effectively. Increasing the battery's lifespan decreases effective costs.
One strategy is to function a subset of the battery cells at a time and exchanging these subsets.

DC/DC convertor

An electric car still uses a 12-volt system to power all of the original 12-volt accessories: Lights, horn, etc.
This may too control a few control circuits for the electric drive framework. However, unlike a gas car, there is no alternator to keep this battery charged. One choice within the early days of EVs was to utilize a profound cycle 12-volt battery, as overwhelming obligation as possible, and energize it after you charge the most battery pack. Usually not satisfactory in case any sum of night driving is aiming.

The solution is a DC/DC convertor. This taps the complete battery pack voltage and cuts it down to a directed yield, comparative to that from an alternator. By tapping the total pack, there's no uneven release. Amperage required is so moo that there's a small impact on the extend. Isolation of the high and low-voltage systems is maintained inside the DC/DC converter. This also eliminates the need for a separate 12-volt charging circuit for an auxiliary battery.

Contactor

A contactor is an electronic switch that can handle high power. It includes a coil that is powered by a low voltage, often 12V in electric vehicles. When the coil is activated, it closes the contacts, enabling electricity to pass through. In electric vehicles, contactors are employed to disconnect the battery pack once the key is switched off, similar to turning off the ignition in a traditional vehicle. For most electric vehicles, contactors with a continuous rating of around 200 amps are suggested, while higher-performance electric vehicles may require contactors that can handle up to 600 amps continuously.

Pot box

Petrol vehicles use a cable that links the accelerator pedal to the engine's throttle. In EVs, this setup is replaced with a connection to a pot box, essentially an electronic throttle connected to the motor speed controller. Most pot boxes are simply an industrial variable resistor (5Kohm is the standard) in robust packaging. Newer motor speed controllers are utilizing digital pot boxes with optical encoders, resulting in increased reliability.

Instrumentation

The main two gauges you will need to add for an EV are a voltmeter to monitor your battery pack voltage and an ammeter which measures the current coming Some electric vehicles feature a "state of charge" meter in addition to a fuel gauge. This meter employs advanced electronics to determine the power usage from the battery and estimate the remaining battery capacity based on that information. capacity you have left. Some vehicles can function as a trip computer, informing you about your remaining range. Those with a reliable battery management system might feature a screen displaying the voltage levels of all batteries in the pack. This provides a useful method for monitoring the condition of individual cells and preventing any from becoming excessively discharged.

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.

Electric and Hybrid Vehicle technology

santoshchikkur — Mon, 29 Jan 2024 16:28:43 +0000

Electric and Hybrid Vehicle Technology: Introduction to Electric Vehicle (LEV), Electric Hybrid Vehicle (TLEV), Utility Vehicle (ULV), Utility Vehicle (ZEV), Electric Vehicle (ULV) & Zero -Emission Vehicle (ZEV)
-Electric Vehicle Basic Components
-Electric Vehicle Batteries
-Electric Vehicle Motor and Controller
-Electric Vehicle Construction Features
-Electric Vehicle Conversion Factors
-Electric Vehicle Converting Factors
-Electric Vehicle Hybrid Vehicle Types - Series Hybrid and Parallel
Hybrid
-Electric Vehicle layouts
-Electric Vehicle Comparison
-Electric Vehicle Power Systems
-Electric vehicle control systems now include regenerative braking. Recent trends in automotive power plants include stratified charged/lean burn engines, hydrogen engines, electric propulsion using cables, and magnetic track vehicles.

Electric And Hybrid Vehicle Technology:

Most of the vehicles on the road these days are arranged with IC engines, which are fueled by fossil control. As we all know, Fossil powers are a well-suited illustration of a Non-Renewable source of vitality, hence a time with no fuel for our Vehicles isn't as well distant
. Also, IC Engine-powered Vehicles contribute a great number of Pollutants to our environment. As a result of these major challenges, we as Automobile Engineers have to come up with new ways to power our wheels and the best solution to this puzzle is the Electric and Hybrid Vehicles.

As the name suggests, Electric vehicles are powered by electricity and use Electric Motors for Traction purposes. Electricity may be stored on rechargeable batteries or any other energy storage devices in the case of electric cars, and electric power may be collected from Generator Plants through overhead lines as in the case of other forms of EV (Electric Vehicle) like electric trains.

HYBRID Vehicles use more than one Power Source to power our wheel. For case, an ELECTRIC Crossover, like the Toyota Prius employments an Electric engine as well as an IC Motor as control plants.

ZEV Concepts

An office named CARB (California Discuss Asset Board) brings in a few Measures to play down discuss contamination, and a curious thought was to energize the advancement and utilize of Zero Outflow Vehicles (ZEVs). The ZEV program was thus born and evolved since its birth in the 1990s. The partial or low-emission categories of vehicles created as a part of the ZEV program are listed below.

TLEV (Transitional Low Emission Vehicles):- Introduction of TLEV categories was introduced in the year 1994 and the primary aim was to reduce emissions. Some of the vehicles manufactured in the 1990s were capable of meeting the TLEV standards without many Engineering modifications if they were operated with “Clean” Fuels. TLEV standard was phased out by the year 2004.

LEV (Low Emission Vehicles):- They are Categories of vehicles with cleaner outflows than TLEVs and all light vehicles sold on and after the year 2004 in California were required to fulfill LEV standards. The development of LEVs is a result of advancements in engineering and technology, like the introduction of techniques like Preheating catalytic converters, Variable Valve Timing, Lean Burn Engines, etc.

ULEV (Ultra Low emission Vehicles):- They are 50% cleaner than the average new vehicle sold in the year 2003. Hybrid vehicles can fulfill ULEV standards like the Honda Jazz Hybrid. They can be defined as cars that produce 75g or less CO2 per kilometer from the tailpipe.

ZEV (Zero Emission Vehicles):- They are 98% cleaner than the Average new vehicle manufactured in the year 2003. They have almost zero tailpipe emission of any Pollutants.
Electric and Hydrogen fuel vehicles are the most excellent cases of ZEVs. Currently, only a few cars meet the ZEV regulations like the Electric- Tesla Roadster, Fuel cell cars like the Mercedes-Benz F-Cell, etc.

ELECTRIC VEHICLES

An Electric Vehicle (EV), also referred to as an electric drive vehicle, maybe a vehicle that employments one or more electric engines for driving. Depending on the sort of vehicle, movement may be given by wheels or propellers driven by rotary motors. All-electric vehicles (EVs) run on electricity only. They are moved by one or more electric engines fueled by rechargeable battery packs. EVs have a few points of interest over vehicles with inner combustion motors (Frosts):

• Energy efficient. Electric vehicles change over almost 59%–62% of the electrical vitality from the lattice to control the wheels—conventional gasoline vehicles as they changed over approximately 17%–21% of the vitality put away in gasoline to control the wheels.
• Environmentally friendly. EVs radiate no tailpipe toxins, even though the control plant creating the power may radiate them. Power from atomic-, hydro-, sun powered-, or wind-powered plants causes no discussed poisons.
• Performance benefits. Electric engines give calm, smooth operation and more grounded increasing speed and require less upkeep than Frosts.
• Reduce energy dependence. Electricity is a domestic energy source.

EVs do, however, face significant battery-related challenges:

• Driving range. Most EVs can as it were go around 100–200 miles time recently reviving, while gasoline vehicles can go over 300 miles sometime recently refueling.
• Recharge time.
Completely energizing the battery pack can take 4 to 8 hours. Indeed a "speedy charge" to 80% capacity can take 30 min.
• Battery cost: The large battery packs are expensive and may need to be replaced one or more times.
• Bulk & weight: Battery packs are overwhelming and take up significant vehicle space. Be that as it may, analysts are working on moving forward with battery advances to extend driving and diminish energizing time, weight, and fetched. These factors will ultimately decide the long run of EVs.

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.

The Challenge of Safety and Security in Automotive Systems Part-4

santoshchikkur — Fri, 19 Jan 2024 14:01:11 +0000

I am continuing my previous article here:

After the utilitarian Security Concept, the specialized Security Concept might be characterized. Within the last stage, the useful security necessities were depicted, and based on them through induction the specialized security necessities are state. These requirements will describe in which way the safety requirements shall be implemented to achieve the safety goals. If there are some safety requirements not allocated to some functional modules, then the allocation shall be made in this step. This implies at least a basic knowledge of the system even if the components should be treated as black boxes; the interfaces between these system components shall be specified. What can be observed here is the fact that decomposition is widely used. Also, a better understanding of the faults and consequences that can appear in the system is mandatory because the last step should be the definition of probability target values for the safety goal and the involved elements.

IMPLEMENTATION OF AN ASIL A SYSTEM. USE CASE

In a Remote Keyless Entry System on an AUTOSAR system and in which way the SWC are developed as services and software components. That structure should be changed if some functional safety requirements are added. There are some cases when the lock button press shall be safety relevant. For example, in the USA the double lock (which will close the car without the opportunity to be opened from the inside) is considered functional safety. The double lock functionality supposes that two consecutive lock button presses within a predefined time (e.g. 3 seconds) shall lead to the closing of the car without the possibility of opening the doors from inside. This can be very dangerous in case somebody is shopping and leaves someone else in the car, but pressing twice on the lock button and being very hot outside can cause the person inside the car to suffocate or any other injuries. From the things stated above, the functional safety requirement may be defined as:
to protect the system against undesired double lock actions means the rejection of the RF telegram in case it is not coming within the predefined time and not from a correct sequence. For this, the following architecture shall be designed. We will assume that the
cryptology protocol is a simple one in which just the telegram counter and the timestamp of the telegram are variable.

The FSsrv(Functional Safety Service) Module is a module that replicates the behavior of the main path RF- RKE Application modules. It is performs the telegram identification, decryption, and authentication, and checks also the integrity of the received telegram. At a higher level, the FSMgr (Functional Safety Manager) is a module that handles the process monitoring and means that checks if the first path outputs are the same as the second path outputs. In this case, the telegram is delivered to the RKE Application to be processed, otherwise it should be rejected. The FSObserver is the module that handles the evaluation of the process monitoring. Only if the outputs of the second path are the same as the output of the first one, the command for double lock be executed. This module acts as a watchdog application and if an error is detected in at least one path, then the current telegram processing shall be aborted and the telegram rejected. Also, it is highly recommended to take into consideration the following:

a) The design of the SWC and entire architecture (or at least of the Functional safety relevant part) shall be a multilayer architecture. Using such architecture, the errors in the high layers are avoided because a high layer application is started only if an application from the next below layer is requesting the start of it. This saves on one hand the CPU load and on the other hand the unwanted behaviors because a high layer application will process a request only if it was already initialized. Something else, the ask will not be taken into thought.

b) All state machine variables should be enumeration types whose values were been generated using the extended Hamming distance algorithm.

c) 2oo3 majority is used for all critical variables and also for the state machine variables. Also, it should be stored in three non-consecutive RAM addresses.

The method described above represents a simple method to develop a safety system with the ASIL A fulfilled in the context of the AUTOSAR concept. Also, the time needed for developing such modules is not drastically increased compared to the development of the non-ASIL systems. (Only with Quality Management).

Conclusion
Standardization of the functional safety concept provides an easier and clearer method to develop a safe system. The entire development process is not as simple as it seems at first because all possible fault causes shall be taken into consideration, but a thorough analysis can lead to the elimination of all “hard” bugs from the software that can provoke damage or injuries to the end-users. Following the methodology for the development of such systems, the accomplishment of the “safety” mission can be very easy. Also, because AUTOSAR provides standard interfaces and modules to assure safety the mission becomes more and more easy. But in the end, the implementation of software to accomplish this seems to be the easiest step if the entire methodology is fulfilled. In conclusion, it needs to be stated that the functional safety concepts need a qualified person to do all the needed steps and it is necessary to distinguish that even safety and security go hand in hand and refer to the same goal, but the concepts are different.

Thanks for Reading.

The Challenge of Safety and Security in Automotive Systems Part-3

santoshchikkur — Mon, 15 Jan 2024 14:02:30 +0000

6. Hardware-specific devices

Security can be assured in functional safety by implementing the following requirements:

b) The ECU shall be protected from flashing (programming) from unauthorized entities. Such requirement can be fulfilled if through programming a flash boot loader application decides based on some logic if the flashed program is an original OEM program or just a “malware” application. Also, this is based on some cryptographic security functions.
c) Diagnosis application for configuring the car variant and setting/getting the DTCs (Data Trouble Code) shall be protected, and only authorized diagnosis applications should be accepted. This is realized with some security codes.
d) Depending on the national laws of the country/countries in which the car is supposed to run the car variant is configured based on them and the handling should be made only in some specific configurations. Not all configurations of parameters shall be available for one car.

FUNCTIONAL SAFETY CONCEPT
The functional safety concept means the description of the functional correlations that should be achieved to fulfill the safety goals and standards. For each safety goal, some functional safety requirements should be defined. This definition of the functional safety concept is made through several steps which will be described below.

The first step refers to Hazard analysis and Risk assessment. In this step, the identification of the hazardous events and assessment of the corresponding risk for humans on the vehicle level and then based on these the relevant functional safety goals are determined. After this step has been realized, it is needed a review from an independent source can be made also by the customer. Here the risks could be classified based on three concepts [8]: severity, frequency of event (known in automotive as exposure) actions (or controllability), and also the ASIL (Automotive Safety Integrity Level) as described in Figure. Severity describes the possible damages to the hardware, equipment, environment, or possible injuries to the people. An action describes the possibility of reducing/avoiding the possible faults and also reducing the frequency to zero or duration of it below a threshold where the damages are controllable.

Each safety requirements are assigned to an ASIL or QM (in case the document quality level is enough for that functionality) and based on this the minimum testing requirement. For example, for an ASIL D (the highest level) the tester should be independent of the development team, and unit testing is required with 100% code and decision coverage. In Figure, the level of the ASIL concept is described.

Below an example is presented (based on the 2010 Hyundai Veracruz Recall issue). Item and Content.

Item ID: #1
Malfunction description: The lamp switch may malfunction.
Possible scenario: A breakdown of the light switch may cause the brake lights to not light up when the brake pedal is discouraged and to stay lit up when the brake pedal is discharged.
Reason category: Typical driving scenario.
Reason for functional safety: Prevent the other participants of the traffic about your intentions.
Severity Collisions with delta v > 40 km. Life-threatening injuries or fatal injuries cannot be excluded.
Frequency: Driving at night
Action: Less than 10% of average drives or read users are normally able to avoid the hazardous by activation/deactivation of the brake lights. It is assumed that most of the drivers see if the driver in front of them reduces the speed, but maybe it will take too much time to brake in a hazardous situation.
Fault Tolerance Time: 500 milliseconds
ASIL Category: B
**Safe State*: The brake lights enlighten when the brake pedal is discouraged and don't light up when the brake pedal is discharged.

The next steps are referring to the description of the Functional Safety Concept. Firstly, it is necessary to describe the functional properties of the use cases found in Step 1. For each of them, another table is made based on the Item ID, and a detailed explanation and quantification of the terms used shall be done. In case that are some emergency methods are needed, it is mandatory to define them. In the next steps, the functional safety requirements on the function level representing the safety strategy shall be created. These will contain in which way the functional safety goal will be achieved and not implemented. Also, it is possible to define requirements outside of the analyzed functions, which will help achieve the safety goal (e.g. mechanical dimensions, warning signs). Identification of the needed elements that can be used for the achievement of this safety goal can be first identified in the current preliminary architecture in case the system is a new one, or already in the frozen architecture if the system is a reuse one. Very important to understand here is the fact that these elements should be functional because the functional safety concept is supposed to be made at the function level. The next steps consist of the definition of warnings and degradation concepts and, the definition of the driver’s action or other endangered person. At this level, it shall be stated what will happen if a dangerous fault has been detected (e.g. driver warning, emergency operation) and also what action is needed to be taken from the driver side to be made in case that warnings of malfunction occur. The final step is the refinement of all concepts/ideas/requirements stated in previous steps. Here it is necessary to describe through diagrams (e.g. UML diagrams) the functional redundancies and the information flow.

NOTE: In this article, I have explained only a Functional Safety Concept. at the last, I will give a conclusion.

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.

The Challenge of Safety and Security in Automotive Systems Part-2

santoshchikkur — Mon, 15 Jan 2024 13:15:19 +0000

AUTOSAR AND FUNCTIONAL SAFETY

For a better understanding of the following that will be described, it is very good to understand the difference between safety and security. These two concepts go “hand-in-hand” [5] but refer to two different things. Safety was described above as the “absence of unreasonable risk” due to hazards caused by malfunctioning behavior of the E/E systems”, whereas “security” means protection of the system from undesired access from other components. AUTOSAR provides some techniques to be taken into consideration when a functional safety system is developed. To develop a system that should be considered fully AUTOSAR compatible some strategies such as the ones from below should be applied.

1. Memory partitioning:

this method allows firstly safety and non-safety SWC (software components) to be developed on the same ECU (Electronic Control Unit). Separation of the components from the memory point of view can be made allowing each component a memory area predefined. For example, such IDEs for developing automotive applications allow developers through the “pragma” C option to define their region for the variables. This job could be made also by the system architect who can define at the start of the project section as “START_SWC_1_RAM_INIT_BYTE_AREA” and “START_SWC_2_RAM_INIT_BYTE_AREA” and also their “STOP_” equivalents. Also, such definitions should be made for each data type and the developers will use these macro definitions while developing their SWCs. Defensive programming could be considered relevant also for this method because allows communication between components using a safe way. In [1], the authors described the safe communication between SWCs using the Real Time Environment Layer. Each SWC provides some interfaces and parameters described in some “ecu config” files delivered by the AUTOSAR software architect. At the micro scale, defensive programming means the cal protection (division by zero, NULL pointers, cast to integral types, range limits, saturation, and overflow/underflow). Also, the ECC (Error Correcting Code) methods are used here to assure the integrity of the FLASH/EEPROM areas. Together with these ECC methods, the consistency check methods and data retention survey are used.

2. Program flow monitoring:

is a method that helps developers implement the required 2oo3 (two out of three) decisions needed in the functional safety systems. In this case, at specified moments, some inputs or outputs could be checked, and also if the requirements about timing constraints are met. In this category, also the support for dual controller plays an essential role because in this case, another “watchdog” controller can supervise the core (main controller).

3. Time determinism and time constraints

modeling allows SWC and Basic Software) modules to know at each point of execution exactly if the timing constraints are met or not. Also, this allows synchronized time bases between networks, components, and hardware jitters and also could determine in the run-time the timing violations parts of code. Also, in the operating system (e.g. AUTOSAR OS and OSEK) these constraints are very clearly specified, otherwise, the task scheduling mechanism is not working properly. we have runnable tasks (e.g. cyclic task, 5ms, 10ms, 20ms, interrupts) and in this case, if the execution of the operations inside of the 5ms task is greater than 30% of the lower task period then in case of some interrupts and maybe at some points where more than one cyclic task operation should be executed, a jitter is introduced in the operating system, and this means that the time base is changing. This is not well because the system is not deterministic and time constraints requirements defined at the beginning of the projects are not met.

4. End-to-end communication protection.

Accordingly, to [6], the concept of end-to-end communication (known as E2E communication) protection assumes that safety-related data exchange shall be protected at run-time against the effects of faults within the communication link. As faults can be considered the following: random HW faults (e.g. corrupts register of the SPI interface, bad design in the overflow range), design systematic errors (e.g. bugs in software in at least one communication stacks, not all requirements were implemented in the communication layer through Virtual Function Bus layer or RTE layer) or maybe environmental faults caused by interferences or natural hazard phenomena. The benefit of using this E2E protection is that the errors (faults) in the communication links will be found in the integration phase.

5. Logic and BIST (Built-In-Self Test) methods

In case functional safety is necessary for the system, then the standards recommend having a chip with BIST capabilities. This means that before setting the chip into functional mode, it is necessary to perform this BIST test to detect any possible memory or hardware errors. (E.g. some memory cells are not usable anymore) coming from the production modes. There are two possibilities for implementing BIST capability: chips can have implemented another controller to perform these operations, or hardware monitors (dedicated devices) for this. e).

6. Hardware specific devices

Devices like watch-dog timers, glitch filters, and self-correcting hardware devices can be classified as being part of this category. Watch-dog timers have the responsibility to lead the program execution or the hardware device (maybe both) in a safe state, in case some anomalies are detected in the software. These anomalies can be writing/reading operations from un-allocated memory, a hung situation that can lead to physical damages in the best case. A possibility to implement this is a periodical task to check the state of the system and if a task is detected to not get out in a predefined time, then the system is considered to be hang-out leading to watch-dog intervention and correcting this behavior putting the program execution in a safe state. Glitch filters are used for critical pins like reset, PLL (phased lock loop), and communication pins for removing noises that can appear due to electromagnetically fields for example. Security can be assured in functional safety by implementing the following requirements: a) An electronic immobilizer (known as IMMO) shall be used to protect the car from driving by unauthorized people or entities. IMMO is built using a transponder chip that communicates through low frequency waves with the key-fob slot and terminal control of the car. The communication is realized using some cryptographic functions such as AES128, HITAG2, or HITAG3, but this is OEM specific.

NOTE: In this article, I have explained only an AUTOSAR AND FUNCTIONAL SAFETY. at the last, I will give a conclusion.

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.

The Challenge of Safety and Security in Automotive Systems

santoshchikkur — Wed, 03 Jan 2024 17:25:11 +0000

Abstraction

At the same time with the growing of complexity E/E systems, the level of safety needed to be fulfilled by the work products increased very fast. Could we determine the way to fulfill a standard safety level for all manufacturers? Are these standardized and applicable? The article sheds light on these standards and provides the basic knowledge to design a functional safety system from the software point of view. Functional safety concepts are described in the ISO 26262[1] standard where concepts such as ASIL, risk assessment methods, and hazard analysis are described very clearly. The article briefly describes these concepts in a manner related to software development. Also, in the AUTOSAR complaint system, the need for functional safety concepts is very huge because in the context of standardized interfaces between modules can lead also to some errors. But for avoiding this, the AUTOSAR requirements provide some methods that are taken into consideration and described also in the article. The last part of the article presents a lightweight implementation of a safety system considering as a use case the designing of a remote keyless entry system.

INTRODUCTION

Nowadays, the automotive industry is continuously changing due to the increasing of customer amount and the complexity of specifications and new technologies but nevertheless Ed “The Internet of Things” (interconnectivity between all electronically devices) because they want their devices interconnected. Also, they should take into consideration the laws and regulations regarding the environment and safety. To resume all things from above can be considered that the main concerns are about building safe, connected, and green embedded systems [2]. In this article, the focus will be on the concepts that make a system more and more safe. To be declared a safe system, it shall fulfill some “functional safety requirements” and the development (including both software and hardware) should be made after a predefined process.

What is interesting is the fact that safety laws were defined also in the ancient world. As an example, the Codex Hammurabi (~1780 BC) [3] may serve as a basis. This was needed in those times because the technology level was very low and a guarantee of the “hand-made” work was more than needed to achieve one “technical” system. But now, do we need such laws because almost all actions of the worker are aided by a computer? In this way, such examples are relevant, and these are some of the most discussed topics, but behind the “open doors,” there are many discussions between the customer and automotive companies. It is known the case of Toyota's problem with the accelerator pedal that kills one person. For this, Toyota calls back about 8.5 billion cars to the garage and also some penalties to the injured people. This causes a lot of waste of money and time also for the company and customers. The Honda Civic has a defective chip in a DC/DC converter that because of a shortcut to the ground blows a main fuse and the motor stops. In Europe about 3751 cars were affected and called back to the producer. Another well-known case is a loss of power steering on the Mazda cars. Three accidents are known and checked currently by investigation agents. These three cases should raise the question: "Are functional safety rules necessary?”

The growing complexity of embedded systems (from both software and electronic points of view) in the automotive industry led to the introducing of an automotive standard to ensure the functional safety requirements. The standard is called ISO 26262 and defines the process for development of the automotive equipment and introduces the actions that should be taken in case of possible hazards caused by malfunctions of electronic and electrical systems in passenger vehicles. The standard is derived from the IEC 61508 standard, the generic functional safety standard for electrical and electronic (E/E) systems. ISO 26262 standards were created and released as a draft version in June 2009 and since then for the lawyers, this has been considered a state of the art. Based on this, a court process could be started against the automotive companies. Confusion between functional safety and quality is made almost every day by unfamiliar developers with this topic. Quality could be defined as something that “missing it annoys”, but functional safety refers to something that “missing it hurts”. From the “Vocabulary” section of the ISO 26262 standard, a definition for functional safety can be considered: “Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems”. In this context, the unreasonable could be considered both unacceptable, and excessive, and risk could be considered the combination of the probability and extent of the damage. Failures of the automotive systems can be failures due to hardware (some shortcuts, low/high voltage) or maybe failures at the design level (e.g. software errors).

The minimization of the risk means at first seeing the reduction of the probability of errors, but this is more complicated than this. In fact, minimization of the individual components will not lead to the elimination of the risk associated with the entire system. Reducing the error occurrence probability below a predefined threshold given by risk assessment of the entire system with all interconnected sub-systems (e.g. software components, sensors, actuators, mechanical devices, external devices) in fact should be considered as fulfilling the functional safety requirements. The following chapters should be considered as key parts of the ISO26262 standard [4]: Vocabulary, Management of functional safety, Concept phase, Product development at the system level, Product development at the hardware level, Product development at the software level, Production, and operation, Supporting processes, ASIL (Automotive Safety Integrity Level) and safety-oriented analysis and Guideline on ISO26262. From these chapters, it could be seen that the standard provides a lifecycle (starting from quotation, concept refinement, development, industrialization, and product validation) methodology for the development of the automotive systems and also adds methods to support tailoring of the necessary activities for the phases of the lifecycle process. Also, the aspects of the functional safety of the entire development (Prototype, Design and realization, Integration and test) process are defined inside these chapters. The risk classes are described using the methods inherited from the automotive specific risk-based approach and the ASIL methods are used for the realization of the specifications for achieving an acceptable risk. Based on these specifications defined previously, architecture is realized, and then the integration and validation test cases and measurement for detecting if the considered risks are below the predefined threshold and are considered acceptable. In this case, the functional safety system is considered a safe one; otherwise, another development cycle should be applied again.

NOTE: In this article I have explained only an introduction that's why I'm not giving any conclusion, in the next article I will explain AUTOSAR AND FUNCTIONAL SAFETY how it is and what are the topics we need to take care. And also, I'm going to explain insights of this topic.

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.

Watchdog Manager Part-2

santoshchikkur — Tue, 02 Jan 2024 07:22:08 +0000

WDGM calculates the status of supervision based on supervision functions and these supervision functions are:

1. Alive indication:

To check if SEs are alive and getting executed a number of times in one supervision cycle. This will help to monitor the execution of SEs and help to check if SE is getting executed too many times or getting executed in less time. For live indication 1 checkpoint in each SE will be required.
i.e. Live supervision is checked for cyclic timing constraints.

e.g.
void cyclicRunnable_10ms()
{
Rte_Call_WdgMCheckpointReached(SE1_ID,CP_ID_1);
/perform some action every 10ms/

}

void cyclicRunnable_5ms()
{
Rte_Call_WdgMCheckpointReached(SE2_ID, CP_ID_2);
/perform some action every 5ms/
}

void cyclicRunnable_20ms()
{
Rte_Call_WdgMCheckpointReached(SE3_ID, CP_ID_3);
/perform some action every 20ms/
}

The system (see code snippet above) has several executables.
3 runnable are selected as Supervised entitiesSE1 (5ms), SE2(10ms), SE3(20ms).
At the time of execution, SE will notify checkpoint reached to WDGM using RTE.
In the supervision cycle (WdgMSupervisionReferenceCycle)100ms WDGM will build the status of live indications.
WDGM will calculate the number of live indications reported by SEs
We can add + and - (minimum tolerance: WdgmMinMargine and maximum tolerance: WdgmMaxMargine) tolerance to expected indications.
WDGM will verify it against expected live indications (WdgMExpectedAliveIndications) and calculate the local supervision status of each SE.
Expected live indications for SE1: 20+WdgmMaxMargine or 20-WdgmMinMargine.
Expected alive indications forSE2: 10+WdgmMaxMargine or 10-WdgmMinMargine.
Expected alive indications forSE3: 5+WdgmMaxMargine or 5-WdgmMinMargine.
If expected indications match then all SE are executing as per design.
Else SE is not executing as per the design
Based on this WDGM will calculate the status of SE's supervision as correct/incorrect.

2. Deadline monitoring:
To check if SEs (non-cyclic) are finishing their execution in the expected time. For these 2 checkpoints are required in SEs and WDGM calculates the time between two checkpoints to determine the execution time of SE. The execution period can have a minimum (WdgMDeadlineMin) and maximum deadline (WdgMDeadlineMax) for execution.

e.g.

void InitDio()
{

RteCall_WdgM_CheckpointReached(SE4_ID,CP_ID_4); // Report Checkpoint 1 Reached

PINSEL2 = 0x000000; //Configure the P1 Pins for GPIO
IODIR1 = 0xffffffff; //Configure the P1 pins as OUTPU

RteCall_WdgM_CheckpointReached(SE4_ID,CP_ID_5); //Report Checkpoint 2 Reached

}

A non-cyclic supervised entity (InitDio) to be supervised using deadline monitoring.
SE will finish execution within WdgMDeadlineMin: 4ms and WdgMDeadlineMin:6ms
SE will require a minimum of two checkpoints for deadline monitoring.
WDGM calculates the time between the first and last checkpoint.
At the start of 1st checkpoint i.e. CP4 in the above code snippet (WdgMDeadlineStartRef) WDGM will note the time stamp
And at the last checkpoint i.e. CP5 in the above code snippet (WdgMDeadlineEndRef) WDGM will note the time stamp
WDGM calculates the time of execution of SE by calculating a difference between the last checkpoint and the first checkpoint.
WDGM will verify the calculated time against the expected time i.e. it should be between W
WDGM will calculate the status of SE's supervision as correct/incorrect.

3. Logical supervision:

Logical Supervision checks if the code of Supervised Entities is executed in the correct sequence.
In Logical supervision, n number of checkpoints is used.

As you know, we use flowcharts to design code and write code based on flowcharts. Now logic monitoring helps to control the flowchart, i.e. whether the logic written in the code matches the design or not, so it is called logic monitoring.

As per the flow chart, we can decide on the checkpoints. These checkpoints will form a graph Refer to the below snippet, a code is given and as per logic checkpoints are added.

void cyclicRunnable_10ms()
{
Rte_Call_WdgMCheckpointReached(SE1_ID,CP_ID_1); // Checkpoint 1
readVoltage();
processVoltage();
Rte_Call_WdgMCheckpointReached(SE1_ID,CP_ID_5); // Checkpoint 5

}

void readVolatage()
{
Rte_Call_WdgMCheckpointReached(SE2_ID,CP_ID_2); // Checkpoint 2
}

void processVoltage()
{

if(voltage >10)
{
    Rte_Call_WdgMCheckpointReached(SE3_ID,CP_ID_3); // Checkpoint 3
    setError();
}

else
{
    Rte_Call_WdgMCheckpointReached(SE3_ID,CP_ID_4); // Checkpoint 4

    clearError();
}

}

WDGM checks if the transition of checkpoints is as expected (i.e. as per logic designed).
Expected Transitions: CP1-->CP2-->CP3-->CP5-->CP1
Expected Transitions: CP1-->CP2-->CP4-->CP5-->CP1
WDGM has an Activity Flag for each graph, initialized too FALSE.
Activity flag helps to decide if the checkpoint reported is 1st checkpoint or not.
Controlled persons report the control point reached to the WGM, e.g. CP1
WDGM will store the current checkpoint and set the Activity flag to TRUE.
When the next checkpoint is reported (CP2) WDGM will store it and check with the previous checkpoint (CP1). WDGM checks if this transition (CP1-->CP2) is valid or not if the activity flag is TRUE.
Similarly, WDGM controls the transition of CP2 - and gt; whether CP3 is valid or not.
WDGM checks the flow of execution.
If CP1 is reported and then CP4 is reported, then this is not a valid transition and WDGM will update the status of SE's supervision as correct/incorrect.

From the above discussion, it is clear that WDGM calculates the status of supervision of SE as correct/incorrect based on the supervision function. Based on the status of each supervision of SE (correct/incorrect), WDGM builds the local status of supervision and based on local status WDGM calculates the Global Status of supervision.

4. Important Configuration Parameters:

If you want to configure WDGM, below are some points you should always keep in mind to configure:

Define Supervised entities and Supervised entity IDs
Define Checkpoints of Supervised entities and checkpoint IDs
Select the supervision Function to be used: Alive/Deadline/Logical. Configure values to the below parameters as per the supervision function selected.

Alive Supervision: WdgMExpectedAliveIndications
Alive Supervision: WdgMMaxMargin
Alive Supervision: WdgMMinMargin
Alive Supervision: WdgMSupervisionReferenceCycle i.e. supervision cycle
Alive Supervision: WdgMFailedAliveSupervisionRefCycleTol (number of failed SE inspections accepted, used to calculate local supervision status).
Deadline Supervision: WdgMDeadlineStartRef
Deadline Supervision: WdgMDeadlineEndRef
Deadline Supervision: WdgMDeadlineMin
Deadline Supervision: WdgMDeadlineMax
Deadline Supervision reference cycle i.e. supervision cycle
Deadline Supervision: WdgMFailedDeadlineRefCycleTol

Program flow reference cycle or monitor cycle Program flow: WdgMFailedProgramflowRefCycleTol.

Define WDGM's initial state: slow or fast
Define WDGM slow state (1000ms) and fast state (200ms) times.
Define WdgMExpiredSupervisionCycleTol (number of local supervisions accepted errors, used to calculate global supervision status)
Operating system application reference.

Conclusion:
In the complex field of automotive software, Watchdog Manager (WDGM) emerges as the silent hero to ensure the smooth running of software tasks. Keeping a close eye on it, keeping track of checkpoints, and organizing the items to be inspected will contribute to a safer and more reliable driving experience. As an important part of AUTOSAR, WDGM's collaboration with Watchdog (WDG) reflects the industry's commitment to improving vehicle safety and reliability. In every journey, WDGM ensures a quiet driving experience and embodies the future of innovation in the automotive industry. Nice roads ahead!

Watchdog Manager

santoshchikkur — Thu, 28 Dec 2023 17:59:14 +0000

Introduction

Watchdog manager (WDGM) is present at the service layer of the AUTOSAR stack as seen. ask of the watchdog manager is to supervise software execution and if it finds an error or flaw in the execution of software, WDGM takes action on it. SWCs use services provided by WDGM, using a client-server interface. SWC are client and WDGM is the server.

Functionality of WDGM:
Functionality of WDGM is

To supervise the SW and to supervise software, the watchdog manager uses supervised entities.
WDGM can change the mode of the WDG driver (Slow, Fast, or OFF).
WDGM updates the trigger condition if SW tracking is good. - If the overall monitor status is not good, reset the ECU or do not set the trigger condition, so that the WDG controller does not trigger the WDG and the WDG generates a restart.

Supervision and Supervised Entity:
What is a supervised entity ?
Supervised entities (SEs) are nothing but runnable within Software Component (SWC), BSW, or CDD.

What WDGM supervises ?

WDGM monitors monitored units in SWCs and verifies that:

Monitored units (software) are periodically started according to configuration, e.g. if a runnable has a frequency of 10ms so in 50ms runnable should have executed 5 times so the watchdog manager monitors if SEs are getting executed a number of times per configuration.
The flow of SEs or sequence of execution of SEs is according to a model (e.g. code is getting executed in the correct sequence).
SEs are getting executed within expected time? (e.g. if executable A should stop executing after 5ms, the WDG controller checks.)

What is Checkpoint ?

How did WDGM get to know that the supervised entity has been executed?

Supervised entities use checkpoint and when a checkpoint (i.e. particular area or line in code may be the start of runnable, end of runnable, or in between some code line of runnable ) is reached while execution, supervised entities notify to watchdog manager that this checkpoint is reached (i.e. it is executed).

Supervised entities use the port provided by WDGM to notify checkpoint reached, using the client server mechanism Function Provided by WDGM is

Std_ReturnType WdgM_CheckpointReached (
WdgM_SupervisedEntityIdType SEID,
WdgM_CheckpointIdType CheckpointID
)

There can be multiple checkpoint in one runnable or a single check point in one runnable that depends on the design and can be configurable.

Watchdog manager keeps track of check points reached indication and calculates the status of supervision based on supervision function. The status of supervision is calculated in the supervision cycle.

What is the supervision cycle?

Frequency at which watchdog manager supervises supervised entities. e.g. if the supervision cycle is configured as 50ms then every 50ms watchdog manager supervises the supervised entities and checks the status of supervised entities as per configuration.

In a system, there are multiple runnable and among them 2 are selected as supervised entities. Supervision cycle of WDGM is configured to 50ms. The cyclicity of SE1 is 5 ms and the cyclicity of SE2 is 10 ms.
Every 5ms SE1 and every 10ms SE2 indicates that a checkpoint has been reached in the WDGM ie. indicates to WDG, that a particular line(or area) in code is reached.

Every 100ms WDGM will calculate the status of SEs based on checkpoints reported by SEs and the supervision function decides if the status of SE is correct or incorrect.

WDGM calculates the local monitoring status based on the monitoring status of each SE in the system. Based on local supervision status WDGM calculates Global supervision status and decides whether SW execution is OK or not.

WDG Triggering:
WDGM is no longer responsible for launching the WDG driver, as of the AUTOSAR version , the WDGM program flag is set to true or false. i.e. sets triggering condition to TRUE or FALSE based on Global supervision status. WDGM uses the function WdgIf_SetTriggerConditionto() to update a flag.

WDG driver reads the flag i.e. triggering condition and based on the triggering condition (if TRUE) triggers the watchdog to avoid reset.

Supervision Functions and working

In the above section, you have learnt that WDGM supervises supervised entities by using supervision functions.
WDGM performs this task in each monitoring cycle, and monitored entities report their status to WDGM using the CheckpointReached (WdgM_CheckpointReached) function. WDGM calculates the status of supervision based on supervision functions and these supervision functions are:

This will be continued in the next article, including examples. Please let me know in the comments below if you have any questions. Thanks for reading.

ASR Network Management

santoshchikkur — Wed, 20 Dec 2023 18:03:53 +0000

Introduction To AUTOSAR

AUTOSAR is a global partnership of leading companies in the automotive and software industries that develops and creates a standardized software framework and open E/E system architecture to advance intelligent mobility.

What Is Network Management

• Network management is the process of managing, managing and operating an information network management system.
• Current network management systems use software and hardware to continuously collect, analyze and transmit data
out configuration changes for increasing

Performance
Reliability
Security • This involves defining the control and, where possible, redefining the network components for which it is intended
Optimal Performance
Minimum Downtime
Proper Security
Accountability
Flexibility

Why Is It Needed?

• As a computer network grows from a handful of machines to hundreds or thousands of connected network devices, the complexity of the network also increases. The ability to manage, monitor, and effectively manage the entire network is part of network management.
• Network management is a multifaceted discipline that provides network administrators with network management tools, protocols, and processes that enable optimized network operations.
• Network management includes several functions important for network optimization and continuous availability.
• This includes defining monitoring and redefining the possible network components it is intended to provide

Optimal Performance
Minimum Downtime
Proper Security
Accountability
Flexibility

NM In AUTOSAR

• The network management interface is a customization layer between AUTOSAR Communication Manager and AUTOSAR bus-specific network management modules (e.g. CAN Network Management and FlexRay Network Management). This is also referred to as Basic functionality.
• In addition, this document describes interoperability between multiple networks connected to the same (coordinator) ECU and using AUTOSAR NM, where means that these grids can be placed synchronously to sleep. This is also referred to as NM Coordinator functionality.
• Support for the NM Coordinator feature is optional. A Network Management Interface implementation can either support only Basic functionality or both Basic functionality and NM Coordinator functionality.
• The Network Management Interface is constructed to support generic lower layer modules that follow a fixed set of requirement for bus specific NM modules. This allows third parties to provide support for OEM-specific or legacy NM protocols, such as direct OSEK NM.

NM In AUTOSAR (Contd.)

NETWORK MANAGEMENT MODULES

ComM
1. ComM handles the user communication mode requests
2. ComM simplifies the resource management for the users
NmIf
Nm is just a general interface that works a dispatcher
between ComM and BusNM
BusNM
1. BusNM coordinates the different NM states and the transitions between them
2. BusNM is responsible for sending/receiving Bus NM messages
BusSM
BusSM handles the communication system dependent Start-
up and Shutdown features

NETWORK MANAGEMENT MODULES

NM In AUTOSAR (Contd.)

•The NM Interface functionality consists of two parts:
– Basic function required to complete together with
the bus specific NM modules, AUTOSAR NM on an ECU. The
Generic Network Management Interface module (Nm) shall
acts as a bus-independent matching layer bus-specific Network
Management modules (such as CanNm, J1939Nm, FrNm, LinNm and
UdpNm) and the Communication Manager module (ComM).
– NM coordination function used by gateway ECUs
to synchronously shut down one or more buses. NM
Coordinator functionality is a functionality of Nm that
uses a coordination algorithm to coordinate the NM stop
in all or one or more independent subsets of the busses
that the ECU is connected to. The ECU uses the NM, n
which actively fills the NM Coordinator functionality
is commonly referred to as an NM Coordinator.
• Note: It is also required that other service layer modules access network management functions exclusively via Nm
and that no bypasses to bus specific NM functions exist.

Wakeup/Abortion Of Coordinated Shutdown

• Nm is not responsible for normal wakeup of the node or the networks this will be done by the COM Manager (ComM).

External Network Wakeup: For both Basic functionality and NM Coordination functionality, Nm will forward wakeup indications from the networks (indicated by the bus specific NMs calling the callback Nm_NetworkStartIndication) to the ComM by calling ComM_Nm_NetworkStartIndication(). ComM will then call Nm_PassiveStartUp(), which will be forwarded by Nm to the corresponding interface of the bus specific NM. EcuM and ComM handle the processing of wake-up events (related to radio receiver and controller status) on channels in the bus sleep mode. No interaction of the Nm apply here. Nm will get the network request from ComM as stated above, depending on the wake-up validation and the respective communication needs.

2.Coordinated Wakeup: Depending on the configuration, ComM can start multiple networks based on the indication from one network.
It is recommended that ComM be configured to automatically start all networks in the NM coordination set when one of the networks reports that the network has started, but this is not always necessary. Since the wakeup of the network is outside the scope of Nm, this is independent of whether the NM Coordination functionality is used or not.

Abortion Of The Coordinated Shutdown: If the NM Coordination functionality is activated and coordinated shutdown has been initiated on an NM Coordination Cluster, dependent on the coordinator algorithm configuration it may take some time before each involved bus is released. If any node on one of the coordinated buses changes its state and starts requesting the network before all networks are released, race conditions can occur in the coordination algorithm.