DEV Community: smbalawad

AUTOSAR compliant multi-core RTOS(Part-5)

smbalawad — Tue, 13 Feb 2024 19:11:53 +0000

Dear readers,
My name is Sadashiv Balawad and I am working as Junior Software Engineer at Luxoft India. Luxoft gave me many opportunities to work on various projects, which inspired me to talk about the importance of multicore Real Time Operating Systems(Part-5)

Timed model with stopwatches
Timed fashions can be prolonged with stopwatches instead of clocks to model the temporal interruption of actions and subsequent resumption. Indeed, for timed automata(TA) and time Petri nets (TPN), time elapses at the equal pace for all gadget components. Hence they can't summary preemptive scheduling rules wherein the execution of a undertaking may be suspended and later resumed on the identical factor.
Several extensions of these models had been proposed to specific the suspension and resumption of actions with the aid of adding the stopwatch belief . Stopwatch automata is an extension that lets in modeling preemptive actual-time responsibilities. For TPNs, several extensions are proposed: Scheduling-TPN , Preemptive-TPN, and Time Petri nets with inhibitor hyperarcs (IHTPN) . The first extension is based on including two new attributes associated with locations: the allocation of the processor or aid and the concern of the modeled venture. The scheduling coverage considered is preemptive with constant priorities. Preemptive time Petri nets depend upon a aid assignment mechanism determining timer progress. IHTPN proposed in controls stopwatches related to transitions the usage of classical arcs and branch inhibitor hyperarcs. However, modeling a actual-time machine with preemptive scheduling the use of timed automata, specially in a multi-core context, isn't always usually easy. It requires an automaton per core, and the utility is described via an automata product. Extended Petri nets with stopwatches include a semantic of the behavior of real-time schedulers and can represent parallel or concurrent structures.

Scheduling studies based on timed models
The time verification of actual-time structures is composed in proving that the machine will always be capable of react in line with its time constraints. Timing validation is, therefore, a decision process that issues project scheduling sequences. Many scheduling studies are based on a representation by means of timed automata or TPNs .

Timed automata and scheduling
Several research use timed automata for the realtime gadget’s verification context and bear in mind scheduling evaluation. G. Behrmann et al. Advocate in a model of timed automata referred to as Priced Timed Automata (PTA). Its semantics is described by way of associating to every transition and vicinity a non-poor real valued value. Their evaluation is composed in seeking foremost offline scheduling with minimal fee the usage of UPPAAL’s model-checker. The authors in focuse on modeling multitasking applications to verify the worst time execution of the obligations the use of timed automata. The modeled applications taken into consideration non-preemptive responsibilities and ordinary service interrupts. The temporal and logical houses of those programs are proven in the UPPAAL model-checker. T. Zaharia and P. Haller present a framework for modeling and verification of embedded microsystems. The mini actual-time packages running underneath a multitasking kernel are defined thru networks of timed automata,
and the properties are specified in UPPAAL’s CTL subset. They focused on preemptive and non-preemptive scheduling duties with special priorities. Besides, supply code is automatically generated. The observe presented with the aid of the authors in proposes an approach to simulate preemptive scheduling the use of UPPAAL. They partner temporal diagrams with timed automata through mapping guidelines to check the time constraints and the impasse.

Time Petri nets and scheduling
Several studies proposed modeling with time Petri to verify complex actual-time systems and analyze schedulability. E. Grolleau and A. Choquet-Geniet present in the modeling of complicated systems with concurrent actions using colored PNs [61]. Their works, however, do not recall on-line schedulers,
and the PN generates an offline collection to execute. The work proposed by means of the authors in [60] shows a formal verification technique for actual-time structures with a preemptive scheduling policy, including Fixed Priority and Earliest Deadline First, with the possibility to use Round-Robin for responsibilities with the equal precedence. The modeling is done with scheduling time Petri nets and additionally lets in the verification of temporal homes for other scheduling regulations. Dianxiang et al. Examine in the scheduling of actual-time
systems the use of time Petri nets. Behavioral houses are separated from temporal properties at some point of verification. Behavioral specifications are verified through reachability righties, and temporal evaluation is conducted primarily based on absolute and relative trigger domains

Formal methods for operating systems verification
Formal verification of real-time working systems is beneficial to guarantee the perfectness of the gadget and to offer proof that the device is properly carried out. This is viable nowadays thanks to several equipment which have been developed in current years.
Several works had been finished on this context that we mention in the following. The list is not exhaustive, and different studies not mentioned in our work can also exist. Some are based totally on formal methods to affirm the same targets as the ones we've for verifying running structures compliant with OSEK/VDX and AUTOSAR requirements. Among the research, some do now not awareness on temporal verification whilst checking the OS and consider other factors of correction, such as the absence of deadlock or compliance with requirements. Other research works are extra interested by verifying temporal residences and schedulability evaluation thinking about the RTOS.

Deductive methods for operating systems verification
Existing formal techniques have been applied in some of studies research for working gadget software the usage of deductive techniques. The authors in [62–66] use evidence assistants to verify officially a real time operating machine. M. Hohmuth and H. Tews in [62] advocate a verification assignment of the L4 well matched Fiasco microkernel. The verification of the C++ resources of Fiasco is executed through the general-purpose theorem prover PVS. Their technique handles kind correctness and protection proof. The verification of seL4 microkernel in is carried out inner Isabelle/HOL. A entire verification method is executed independently of the application, from the high-degree specification of the kernel conduct to its secure execution.
Their evidence, however, is constrained to the validation of assumptions about the right functioning of the hardware and compiler. In , the Coq proof assistant is applied to the
formalized specification description of FreeRTOS - to affirm the correctness of significant homes expressed in Separation Logic. In, authors implemented an Earliest Deadline First (EDF) actual-time scheduling policy in seL4 microkernel and provided the
time control and periodic project model. Fengwei et al.recommend a verificationframework for preemptive operating gadget kernels. The framework allows the definition of the version by using a specification language and its verification by using program common sense. All proofs are in Coq, and the verification of the useful correctness of the kernel is done. Gu et al. [66] develop a certified concurrent OS kernel mC2 using CertiKOS and Coq proof assistant. They affirm its correctness and machine-call specification.

Thank you

AUTOSAR compliant multi-core RTOS(Part-4)

smbalawad — Tue, 13 Feb 2024 17:59:41 +0000

Model-based verification methods
Among the formal methods, model-checking is an automated technique to verify that amodel of a device conforms to a specification expressed as a property. This specification defines the requirements for the expected conduct of the gadget. The verification is achieved through exploring the model’s states with the assist of algorithms and allows to guarantee properties. Achieving the machine abstraction and specification is a critical
step that can require device mastery and information within the methods used. The version have to also be accurate and as near as viable to the machine from a behavioral point of view. Therefore, the belongings verification ought to be the equal for the device and its version.
The device is described via a version that abstracts the machine, most usually using state machines consisting of automata, Petri nets, and technique algebras. The preference of version relies upon on its expressiveness, i.E., its ability to represent many device traits. In trendy, the expressiveness of a model may be opposed to its simplicity of verification.
As an expressive formalism can be very helpful in modeling, it can additionally be blockading in the verification segment. The specification of the gadget is described with the aid of homes that may be expressed within the form of observers of the version or using a particular logic such as Linear Temporal Logic (LTL) [27] and Computation Tree Logic (CTL) or the temporal extension of the latter: TCTL . In, L. Lamport decomposes the correctness homes of a system into categories: safety houses which specific that an unfavored situation will by no means happen, and liveliness residences which ensure that underneath certain conditions, the preferred situation will eventually arise. These two categories of residences also can be decreased to a reachability verification that appears for a route in which the favored scenario is met.

fig 2- Model-Checking Approach.

Once the model and its specification are constructed, an analysis of whether the version satisfies the specification is performed. This evaluation explores all viable executions of the machine from its preliminary country. The generation of a counter-example is automated when the assets is false in the shape of an execution trace starting from the preliminary state to the state violating the assets. Thus, the version-checking approach is carried out on
two predominant levels (modeling and specification verification), as proven in Figure 2.
With model-checking, the person does now not interfere in the verification method and effortlessly identifies the states of the system inflicting its violation through counter-examples
generation. The main advantage is, consequently, its computerized man or woman. However, the approach is restricted by means of computing capacities. The trouble of the combinatorial explosion
is due to the exhaustive exploration of the system’s state area. Several discount studies are proposed to cope with this limitation of exhaustive strategies .

Timed models
Time-based fashions allow the modeling and verification of actual-time programs by considering mission execution times and synchronization mechanisms. Adding temporal parameters to the utility can restriction its behaviors, limiting the quantity of states of its model. Moreover, it's far vital to check the quantitative temporal residences to identify specific motives for failure. The main households of models are extended with time, including timed automata and time Petri nets .

Timed automata
A timed automaton is an extended finite automaton with clocks to keep in mind time. A finite automaton is an abstract gadget with a constrained number of states that accepts an input alphabet to adapt its kingdom. The values of the clocks boom at some point of the execution of the timed automaton and may be associated with constraints known as invariants. The invariants of the device manipulate the length for which the machine can continue to be in a given location and could depart it once the invariant is no longer satisfied. The clocks are then reset to zero whilst the transition is fired, and the related action is finished.
The formalism is supported by several fashions checking equipment, Among them, UPPAAL is one of the first-class-recognized and maximum efficient tools. The tool is conceived for the modeling and formal verification of actual-time structures the use of a network of a timed prolonged finite automaton with useful functions written within the UPPAAL language. Kronos, proposed with the aid of S. Yovine , is a software tool that lets in customers to affirm the specs of a real-time device for the duration of its layout phase. T.Amnell et al. [37] recommend
the TIMES tool as a scheduling analyzer primarily based on timed automata and their extensions. It helps simulation, formal verification and code generation of the model. TIMES gives a graphical editor that permits the person to specify the parameters of a fixed of responsibilities which include priority, closing date and execution time. Nevertheless, the tool does now not allow the evaluation of challenge sets with shared assets.

Petri nets and time
Petri nets have foremost temporal extensions: Time Petri nets [39] and the timed Petri nets . Time Petri nets are an extension of the classical Petri internet called an area transition internet, in which every transition is related to a time c programming language. This c programming language
specifies the viable firing dates. The 2d temporal extension of Petri Nets is Timed Petri Nets where transitions are fired as quickly as viable even as a transition may be fired inside a given c programming language for Time Petri Nets. Time is therefore represented by means of minimum(or exact) periods for Timed Petri nets. Time also can be related to transitions (T-time), locations (P-time) and arcs (A-time). T-time Petri nets are the
most broadly used in actual-time structures and those used in our modeling in this thesis mission, and they have the identical expressiveness as Turing machines , opposite to Timed automata. We present the formalism with its color extension in element in coming chapter

I will try to explain more this topic in next part

Thank you

AUTOSAR compliant multi-core RTOS(Part-3)

smbalawad — Sun, 11 Feb 2024 18:46:37 +0000

FORMAL METHODS FOR REAL-TIME SYSTEMS
Introduction
Formal techniques ensure machine self belief, and the emergence of latest software equipment has brought about their usability. We study in this chapter the existing formal verification strategies in the literature, specializing in their use for verifying the utility’s schedulable and actual-time running structures. We rely on the two most popular households of formal strategies: theorem proving and version-checking. In theorem proving, we examine infinite systems laid out in the suitable mathematical good judgment to confirm the righties and offer proof. On the opposite hand, in model-checking, we examine whether or not the
favored belongings is happy via exploring the whole country space of the finite constructed model. It is an automatic and efficient approach that also can cope with the problem of kingdom area explosion when the quantity of states grows to infinity with growing variables and their awesome values in addition to components.

Formal verification methods
Testing is extensively used in exercise, even though it is simply not possible to apply it in extraordinarily crucial structures wherein test records could reason damage if errors are made earlier than actual deployment. Another solution is to simulate the conduct of the system on a laptop. The simulation does now not paintings at once at the actual gadget however on a model. A version represents an abstract illustration of the actual device, commonly written the usage of mathematics or good judgment. Both testing and simulation are widely used in commercial programs,
and their use has demonstrated to be very beneficial. A disadvantage, but, is that it isn't always commonly feasible to simulate or test all viable scenarios or behaviors of a given machine.
Here are some examples where trying out and simulation failed. The Air France Flight 447 crash in June 2009 caused the loss of life of the people on board. When the plane became flying from Rio de Janeiro to Paris, the hurricane triggered the airspeed sensors to freeze, leading the autopilot to disconnect. The pilots misinterpreted the noise, main the aircraft to ram into the ocean. The worst is knowing that the crash could have been avoided. In
August 2005, The Boeing 777-two hundred of Malaysia Airlines Flight 124 unexpectedly and with out caution climbed better than anticipated. The group faced a supposedly impossible situation where the stall and overspeed signs became on simultaneously. The plane landed approximately 18 minutes into the flight, and the failure came about in its air records inertial reference unit. One of the 2 accelerators controlling the airspeed failed, and due to
a software anomaly, the second one used incorrect statistics from the first accelerator. Another instance is the failure of the Computer Aided Dispatch (CAD) in the London ambulance service. The inquiry group’s investigations display that the gadget and the resilience of the hardware had been no longer completely examined earlier than implementation.
Formal verification, in assessment to checking out and simulation, permits the exhaustive investigation the use of static analysis primarily based on mathematical fashions to verify the accuracy
of hardware or software behavior. Accidents can then be avoided if the structures are established and analyzed mathematically. Two categories exist, deductive strategies based totally on theorem proving and automatic strategies primarily based on version-checking.

Theorem-based methods
Formal theorem proving is one of the quickest developing regions in latest years, that verifies the correctness of the device’s homes through mathematical reasoning. With the new effective equipment of theorem provers, unsolvable problems several decades ago are being handled these days, and new demanding situations are emerging. Many fields, which include computer technological know-how, biomedical, economics, device gaining knowledge of, and artificial intelligence, have efficaciously used theorem provers. It gives a statement from a logical set of axioms or hypotheses to check a gadget’s houses defined with mathematical common sense. Theorem provers may be divided into two categories:

- Interactive Theorem Provers (ITPs),
Referred to as proof-assistants : this method lets in proofs to be built with a reliance on user guidance. It entails human interaction with the device within the formal evidence development process .Coq and Isabelle/HOL are a number of the most well-known present gear Their overall performance is extraordinary, and that they formalized and proved many theorems in the first hundred theorem listing

- Automated Theorem Provers (ATPs):
: This kind is composed in constructing the
proofs mechanically via the tool with out consumer intervention primarily based on a description of the device to be verified, a set of axioms, and inference rules. Current ATP structures can clear up non-trivial troubles, consisting of the Robbins trouble [ solved by the EQP automated theorem proving program for first-order equational common sense In practice, the complexity of most issues is considerable and can not be solved inside useful resource limits. Thus a massive issue of ATP studies is developing more effective systems which can resolve troubles in the identical aid constraints
Theorem-proving techniques have barriers, which include the sluggish procedure of building proof, in spite of automated provers. In addition, most theorems do not aid graphical and visualization gear, and common sense isn't always sensible as a language. The technique requires a high-degree of understanding on the consumer’s component, specially for ITPs that require heavy InterMation and lots of energy. These drawbacks are consequently an impediment to adopting theorem proving while handling complicated structures. However, destiny works on this path
continue to enhance faster and extra efficient provers and cause them to greater suitable for the commercial region through trying to combine specific strategies.
I will try to explain more this topic in next part

Thank you

AUTOSAR compliant multi-core RTOS(Part-2)

smbalawad — Wed, 07 Feb 2024 17:48:06 +0000

Motivations
Our goals are two;
1) To test and assess the behavior of the real time operating system (RTOS) by subjecting it to application models that comply with the OSEK/VDX [6]. Autosar [3] standards. This will help determine whether the RTOS meets the standards.
2) To examine the issues related to using this operating system, such, as multi core schedulability, in real time scenarios.

When it comes to understanding the behavior of a core RTOS we face three main challenges;
1) The operating system is influenced by various stimuli, especially those related to real time operations.
2) The applications and code blocks of the operating system are run at the time, on cores.
3) Certain portions of the operating systems code can be executed concurrently by cores, such, as the StartOS service and Spinlock services.

Choice of the model
To achieve this goal we utilize methods, the technique of model checking. Model checking is an approach to handle concurrency and interactions, between parallel processes, which often give rise to errors in systems. These concurrency related errors are intricate and challenging to reproduce or identify during testing due to the interleavings, in the execution of parallel processes. However model checking is excellently suited for detecting concurrency bugs and proving their absence in a system. It relies on exploring the state space of the system model to verify the correctness of properties throughout the execution path.We apply our methodology to Trampoline, a real time operating system that supports cores and complies with OSEK/VDX and AUTOSAR standards.

Because it is written in C, a model-checker running on concurrent C programs like [9] may be useful with the RTOS we are dealing with; however, calling services goes through assembly code that would require to be formally analyzed within the complete hardware architecture model and hence not portable. Additionally, it is not enough to only check for properties of C-program but because they are checked against real-time stimuli causing consequent interruptions. Therefore, we need a time-aware modelchecker since we are taking into account execution times of application tasks. The genericity of the approach does not take into account execution times of OS instruction blocks. Information about timing should hold only for a specific hardware.

employs timed automata that can replicate concurrency and its interleaving. The only problem with it is that it cannot imitate the simultaneous execution of a code sequence on many cores unless the code sequence model itself is cloned. As such, time Petri nets will be used for both concurrent and time modeling. We will add to them by defining colors in such a way that multiple tokens with different colors representing cores on which operations are executed can traverse the same sequence of transitions.

** Scientific contribution**
The results of your thesis provide three main contributions to the goals set in the preceding section. First is the contribution touching on design paradigm for modeling. Since Petri Nets do not by default capture simultaneous access to shared resources and
time, as is often required when controlling multi-core real-time systems, we propose an extension of this formalism with colored transitions and a high-level function i.e., a predefined syntax manipulating different types of expressions made up of variables. Along with sequential pseudo code, High-Level Colored Time Petri Nets includes both timed multi-enablement of transitions and reachability problem that is decidable for this model.To represent the real-time application as a sequence of RTOS system calls instead of the multi-core RTOS that reproduces its control flow, we use this extended formalism, which uses similar variables with implementation ones.
The second contribution has two parts. First is the formal verification of the RTOS conformity to the AUTOSAR standard using test-suite modelling that includes several HCTPN applications. Second, we verify the mechanism for inter-core synchronization in
the context of concurrent OS service execution. AUTOSAR conformance testing relies on requirements checking. For this, we have eighty multi core operating system (OS) requirements.
Each specification is enforced by an evaluator that measures compliance. Observer models are benign i.e. they do not interfere with system operation. The cores are associated with Petri net transition colors. We perform model-checking to validate the AUTOSAR specifications. Result from the approach shows that the present operating system model meets AUTOSAR expectations.
This paper concludes with a focus on verifying simultaneous service calls execution on cores for safety analysis as part of the AUTOSAR compliance veri cation of multi-core RTOS and since these cases are synchronous, they do not include concurrent situations; However, when it comes to verifying simultaneous service calls execution on cores for safety analysis as part of the AUTOSAR compliance veri cation of multi-core RTOS and since these cases are synchronous, they do not include concurrent situations;

fig 2- Formal verification approach
Finally, we offer a verification method to decide the schedulability of real time applications with established preemptive duties on the distinct multi-middle RTOS model. It also allows figuring out beneath which temporal conditions the application is schedulable the usage of parameters at the firing periods. Verification of real-time applications schedulability is commonly accomplished the use of a very abstract device illustration, which poorly supports inter-challenge dependencies. We represent every software mission through a Petri net whose transitions deliver Best-Case Execution Time and Worst-Case Execution Time [𝐵𝐶𝐸𝑇, 𝑊𝐶𝐸𝑇] firing durations and make carrier calls to the OS. Preemption is supported by using stopwatches. We correctly examine worst-case reaction time computation for based preemptive duties in multi-middle structures. Thus, our contribution is a whole method to verifying the schedulability of aactual-time system, the AUTOSAR compliance of multi-center RTOS, and the inter-center synchronization mechanism involved in concurrent OS provider execution the usage of High-Level Colored Time Petri Nets (HCTPN). The technique steps are illustrated in Figure 2 We depend upon the Roméo model-checker device for the verification, to be had beneath a free license

I will try to explain more this topic in next part

Thank you

AUTOSAR compliant multi-core RTOS

smbalawad — Sun, 04 Feb 2024 17:13:05 +0000

INTRODUCTION
Embedded structures are actually found in numerous contexts and applications in our normal lives. These structures have advanced and need to apply more and more complicated hardware and software architectures to attain the required stage of overall performance. In addition, the call for excessive-overall performance computing amongst applications has brought about a rise in using multi-middle chips. Embedded structures are required to implement all the preferred functionalities and validate each the purposeful and temporal accuracy. Considering the time, the embedded system is designed as a real-time gadget for safety-important motives. A actual-time device interacts with a complex external surroundings and have to meet cut-off dates, guarantee timing constraints, and remember the correctness of the computation. The design of this type of system have to hence be predictable, i.e., its behavior to be predicted regarding the time requirements. The real-time system
has three classifications:

• Hard real-time System: Failure to meet the deadline and time
constraints in this gadget has disastrous results;

• Soft real-time system: This system can now and again pass
over its cut-off date without severe effects;

• Firm real-time system: The machine lets in every so often
missed closing dates with a specification of which closing dates
can be lost. If the machine misses more deadline than defined
inside the specification, the system fails and can reason
serious outcomes

As software-based functions increase, Real-Time Operating Systems, also known as RTOS, end up extraordinarily critical. This gadget serves as an interface between software program and hardware and presents all vital functionalities. The RTOS is hence liable for coping with hardware assets and scheduling software processes.
In order to growth confidence and save you unexpected behavior, system verification is essential. It is crucial to carry out time verification and validation to demonstrate that the machine will constantly be capable of react in keeping with its time constraints and that the task scheduling sequences will usually be appropriate.
The real-time system (RTS) structure, as represented in Figure 1, consists of a software thing, i.e. Programs that have interaction with a Real-Time Operating System (RTOS), and a hardware component that allows its execution

fig 1-Real-Time Systems

Software components
In the RTS software utility, obligations talk with every
different by exchanging messages or through synchronization mechanisms. The actual-time operating gadget manages the hardware resources and provides a scheduler. The scheduler is in rate of the order wherein tasks are done to make sure the closing dates are reputable. The RTOS evolution is formalized with requirements; In the avionics and automobile industries, ARINC 653 [1],OSEK/VDX, and AUTOSAR [2, 3] requirements advise implementation regulations for software and hardware independence and necessities that
an operating system need to ensure. Thus, requirements provide specs for growing an RTOS with various functions, inclusive of scheduling coverage, memory, and timing safety.

Hardware component
The RTS hardware incorporates processors, memories, input/output devices, and extra components. The hardware structure is often classified according to the wide variety of processors and cores
Serious incidents can occur if errors are gift within the real-time software program gadget. Therefore, growing a pc gadget that is freed from errors is imperative. Testing is a fashionable approach for identifying software application errors. Because it isn't exhaustive, it does now not assure the removal of all errors. Furthermore, it is insufficient for actual-time vital structures where a failure could have disastrous consequences. Formal verification is a solution to growth the implementation reliability of the gadget. It is a preferred for the car enterprise.
Verifying that the gadget’s specification residences are happy is needed to establish that the device is accurate. Safety and liveness are the two maximum tremendous styles of those homes. While the safety property suggests that an unexpected occasion will no longer occur, the liveness belongings usually implies that a program’s finite parts will entire their execution if their input is correct. In addition, it is vital to make certain that the running system behaves as expected. In reality, the whole gadget’s reliability relies upon on the running device that handles its complexity. Therefore, RTOS must adhere to the
OS specification to ensure security and practical safety. That emphasizes the need to use a formal method to provide machine verification.
Compliance verification of an OSEK/VDX and AUTOSAR working machine is usually completed with a test suite including multiple programs. The conformance check suite is thus performed at the RTOS to attain the usual certification. Contrary to software program checking out techniques that examine software program behavior to reveal defects, formal techniques examine the behavior of the software program to prove the presence or absence of defects. Formal verification procedures have tested to be incredibly effective. They allow mathematically proving a device’s specification.
I will try to explain more in the next part.
Thank you

"A Comprehensive Guide to Advanced Driver Assistance Systems, Levels, and Sensors(Part-3)"

smbalawad — Sun, 28 Jan 2024 17:44:16 +0000

My name is Sadashiv Balawad and I am working as Junior Software Engineer at Luxoft India. Luxoft gave me many opportunities to work on various projects, which inspired me to talk about the importance of Advanced Driver Assistance Systems(Part-3)

Top 7 Applications of ADAS in 2022
The placement of cameras in the automobile includes developing emblem-new artificial intelligence (AI) additives that use sensor fusion to pick out and compare objects. Image reputation software program, ultrasonic sensors, lidar, radar, and sensor fusion can integrate vast amounts of statistics. This technology can bodily reply quicker than a human driver, examining streamed films in actual-time, decoding what it sees, and determining how to react. The following applications are a number of the most outstanding ADAS structures:

1. Adaptive cruise control
Adaptive cruise manage (ACC) is especially powerful on highways, where drivers often conflict to maintain consciousness of their speed and motors within the environment for prolonged intervals. Based at the moves of close by items, advanced cruise manipulate might also mechanically boost up, slow down, and once in a while forestall the vehicle.

This smart driver assistance era permits drivers to pick out a velocity. Based on the distance among the auto in front, it'll mechanically apply the brakes and boost up as wished. As era progresses, you can now discover structures prepared with a stop-and-go function, which robotically brings the car to a complete halt at the back of any other automobile after which speeds up returned as much as the velocity of traffic.

2. Blind spot monitoring
Blind spot detection gadget sensors provide drivers with statistics that could in any other case be not possible to get admission to. Some structures produce a caution sign after they identify an obstruction in the motive force’s blind quarter (e.G., the driving force tries to go into an occupied lane). 78% of all lane-change injuries occur because the motorist was ignorant of the chance in the new lane.

Blindspot warning systems aid drivers in detecting and alerting cars which might be lingering in their blind spots and can not be visible. It generates a haptic warning, both visual, auditory, or both, to tell the driver that merging or converting lanes is dangerous. Many systems may even inform you when you use your signs even as any other vehicle is inside the subsequent lane.

3. Adaptive headlights
Adaptive headlights react to the automobile’s speed and steering wheel rotation to follow the direction of the street and decorate night time vision by means of lights the roadside in preference to the street itself. When a lock is connected to the projectors in the front of the headlight housing, they may sync, changing the beam to comply with the street and aiming lights downwards to lessen glare for oncoming vehicles. Adaptive light control adapts a vehicle’s headlights to outside lighting conditions.

Glare-unfastened high beams and pixel lights employ sensors to evolve to the darkness and environment of the car with out disrupting drawing close motorists. This revolutionary headlight application detects other vehicles’ lighting and redirects the automobile’s lights faraway from different drivers on the road, preventing them from being in brief blinded.

4. Following distance warning
Following distance caution (FCW) monitors the speed and distance of cars at once in front using various incorporated technology consisting of lasers, radar, infrared, ultrasonic, visual imaging, and from time to time together with cameras. This will notify the motive force of an imminent collision with some other automobile or object without delay in its path. FCW systems can avoid nine to 53 percent of rear-give up incidents and 19 to 60 percent of wounded drivers.

5. Automatic parking
Automatic parking signals motorists to blind areas, letting them understand while and how to show the steering wheel and are available to a entire prevent. Rearview cameras provide a extra view of the surroundings than ordinary aspect mirrors. By merging the information of several sensors, a few frameworks may additionally even end parking without the motive force’s help. It is also applied in self-provider valet parking. The automobile’s sensors offer data on its location, its destination, and the most secure route to get there. This statistics is cautiously reviewed and utilized to manipulate the automobile’s acceleration, braking, and maneuvering till it's miles efficaciously parked.

6. Navigation system
Using on-display instructions and audible cues, navigation structures allow drivers observe a course even as preserving their interest to driving. Specific navigation structures can show precise visitors records and, if required, recommend an exchange manner to avoid traffic bottlenecks. To prevent diversion of driving force attention, superior structures may probably include heads-up presentations (HuD).

Night vision structures allow drivers to view gadgets that would otherwise be tough or not possible to peer at night. Two forms of night vision installations are typically available: Passive night time imaginative and prescient structures that rely on the thermal power launched via cars, animals, and different objects, and of route, lively night imaginative and prescient systems.

7. Detection of driver drowsiness
Driver drowsiness detection alerts drivers to threats of tiredness or other ability avenue dangers. There are numerous strategies to tell if a driver’s awareness is dropping. In one scenario, sensors can examine the motive force’s head movement and pulse price to see whether they propose sleepiness. Other systems send out driving signals akin to lane-detecting caution alerts.

Thank you

"A Comprehensive Guide to Advanced Driver Assistance Systems, Levels, and Sensors(Part-2)"

smbalawad — Sun, 28 Jan 2024 17:07:52 +0000

Adaptive Light Control
If you’re using on a foggy night time, with limited visibility, the Adaptive Light Control adjusts your automobile’s headlights in reaction to diverse using situations, providing most visibility and protection on the road. Whether you’re riding through a protracted tunnel or in heavy rain, this technology ensures your headlights are constantly adjusted for surest lights.

Automatic Parking
It is terrifying to park your vehicle in a decent area after having to manoeuvre it a couple of times. That’s where the Automatic Parking technology takes the pressure out of your parking enjoy through mechanically steerage your car into a parking spot, whether or not you’re parallel parking or navigating a limited parking space.

Autonomous Valet Parking
Imagine pulling up to a parking area, stepping from your car, and having it park itself. Futuristic? Yes. Possible? Also, yes. Autonomous Valet Parking gives a trouble-loose parking revel in. With this modern-day technology, you may drop off your automobile at the doorway of a parking facility and feature it park itself.

Navigation System
If you’re driving in a new town, and not using a nearby guide to help you, the Navigation System acts as a personal guide. Whether you’re exploring a brand new metropolis or taking a avenue ride, modern-day Navigation Systems make foldable maps redundant even as making it less difficult a good way to reach your destination.

Night Vision
This cutting-edge technology illuminates the road in difficult low-light situations. If your vehicle is prepared with night time vision, you may navigate quite simply and comfort, even in the dead of night time. The superior imaging generation detects objects and indicates them to your automobile’s display, making sure which you’re aware of your surroundings.

Automatic Emergency Braking
This is a existence-saving generation that uses sensors and cameras to stumble on ability collisions and automatically apply the brakes to keep away from or minimise the effect. The automated emergency braking works to maintain you and your passengers safe at all times.

Driver Monitoring System
This generation is ready with cameras and sensors to hold you alert and targeted on the street. It additionally video display units your riding behaviour and signals you if it detects any symptoms of fatigue or distraction. With this feature, you can ensure that you’re always alert, aware, and using within the first-class possible situations.

5G and V2X
These technology raise your automobile’s connectivity, permitting it to speak with other automobiles and infrastructure on the road. With 5G and V2X, you could enjoy a more secure riding enjoy, with real-time site visitors updates for stepped forward direction guidelines and warnings to help you keep away from injuries and visitors jams.

Lane Departure Warning
This era indicators you if you’re drifting out of your lane, supporting you live on track and avoid accidents. With lane departure caution, you can pressure with confidence on even the busiest roads, knowing that you’re no longer making the roads hazardous for your self and other street users.

Blind Spot Detection
This technology right away signals you if there’s a automobile on your blind spot, assisting you convert lanes adequately. With blind spot detection, you can be sure that you’re privy to all of the surrounding automobiles, making sure that you make secure and knowledgeable selections even as driving.

What are the special ADAS Components?
Several additives make up an ADAS gadget.some of the important ones:

Sensors
These encompass cameras, radar, lidar, ultrasonic, and other sensors that detect gadgets and provide facts approximately the automobile’s environment.

Electronic Control Unit (ECU)
This is the mind of the ADAS system, which tactics the records from the sensors and determines the suitable response, along with applying the brakes or steerage the vehicle.

Actuators:
These are the bodily components that perform the instructions from the ECU, inclusive of the brakes or the steering machine.

Human-Machine Interface (HMI)
This is the interface among the ADAS device and the motive force, supplying facts and remarks to the driver about the machine’s operation and any ability risks detected.

Data Storage
ADAS structures regularly save records, consisting of pix from cameras or information from sensors, to improve their overall performance and provide valuable facts for future evaluation and improvement.

Connectivity
Many contemporary ADAS structures are connected to the internet, allowing for over-the-air updates and far off tracking and diagnostics.

What is the destiny of ADAS?
As we march into the age of generation and the demand for safer, greater efficient and stress-free riding reports grows, the development of ADAS technology is predicted to flourish. This is going to bring about the advent of new and stepped forward technologies to offer drivers with a more degree of protection and luxury.

As self sustaining driving technologies retain to enhance, the variety of fully self sustaining vehicles is bound to upward push. These vehicles will provide drivers with an unheard of level of protection, protection, and convenience.

ADAS technologies are an vital part of the automobiles of the destiny, and right studies and improvement tasks will play a considerable position in shaping the future of driving. It’s safe to say that we can stay up for a future in which riding is more secure, greater green, and greater exciting than ever before.

Differences between ADAS and Autonomous Driving
ADAS and Autonomous Driving are two extraordinary technologies. While ADAS refers to a group of technologies designed to help improve the general safety of the using enjoy, autonomous driving, then again, stems from the idea of cars being smart sufficient to power themselves with out human intervention.

While automobiles just like the MG Astor with the today's ADAS technology have become extra nuanced and complicated, they nevertheless want the driver to be in control of the automobile always. But, vehicles just like the Tesla Model S, which might be ready with self sufficient riding, can power themselves, with little or no intervention from the motive force.

This topic try to explain more in next part

Thank you

"A Comprehensive Guide to Advanced Driver Assistance Systems, Levels, and Sensors"

smbalawad — Sun, 28 Jan 2024 15:54:48 +0000

What is ADAS?
Advanced Driver Assistance Systems, typically called ADAS, embody a suite of contemporary technologies and features expressly crafted to strengthen driving protection and convenience. Utilising an array of sensors, cameras, and different state-of-the-art devices, these superior structures can discover ability hazards and assist drivers in fending off injuries or collisions.

ADAS includes a spectrum of capabilities, which includes, however not restrained to, lane departure caution, adaptive cruise control, all of These functions come collectively to help drivers remain focused on the road and stay out of damage’s way.

Without a doubt, ADAS technology represents a first-rate step in vehicle safety and is an increasing number of universal in contemporary cars. By helping drivers in navigating the street and evading accidents, ADAS imbues riding with an introduced layer of protection, making it a extra fun revel in for all road users

How does ADAS work?

Autonomous motors are substantially reworking the automobile industry, making the next era of superior, mobile-related gadgets a actual opportunity. Advanced Driver Assistance Systems (ADAS), are broken down into diverse chips which can be known as systems on a chip (SoCs). These SoCs work by means of connecting the sensors through digital manage units (ECUs) to operate effectively.

ADAS are a group of technologies that work collectively to provide assistance to drivers and beautify their riding enjoy. It makes use of a aggregate of cameras, radars, LIDARs, and ultrasonic sensors to provide the automobile with a well-rounded know-how of its surroundings. These systems technique the influx of statistics and speak with the car’s ECU, Radar, LIDAR, GPS, and Wheel Encoder which makes critical and timely choices and adjusts the automobile’s movements thus.

All those technology paintings together to enhance using protection, lessen the threat of accidents, and make the roads safer.

What are the different ADAS Levels?
There are six tiers of riding automation, as described through the Society of Automotive Engineers (SAE). As we development thru those ranges, drivers are granted extra freedom and autonomy, as the obligation for riding responsibilities shifts from the human operator to the automatic systems. The six Levels of ADAS are shown below:

Level 0: No Automation
The driver is accountable for all aspects of riding, and there may be no automation concerned.

Level 1: Driver Assistance
The car capabilities one automated machine, inclusive of cruise manage or lane departure warning, that assists the motive force.

Level 2: Partial Automation
The automobile capabilities or more computerized systems that paintings in tandem to assist the driving force with guidance, braking, and acceleration.

Level 3: Conditional Automation
The automobile can manipulate maximum components of riding; however, the driver has to be prepared to take manage if important.

Level 4: High Automation
The car can perform all driving duties underneath positive situations, such as on a toll road or in a particular geographic area.

Level 5: Full Automation
The automobile can perform all using tasks in any scenario without any human intervention.

What is the difference among Active ADAS and Passive ADAS?
Active ADAS actively intervenes to save you accidents, even as passive ADAS presents comments after an accident occurs. Active structures are more complex and highly-priced but have the ability to seriously lessen accidents, whilst passive systems are simpler and much less pricey, but simplest mitigate the severity of accidents.

Here are a number of the common points of difference between Active ADAS and Passive ADAS:

What are the different types of ADAS Sensors?
The extraordinary ADAS sensors work in tandem to provide a complete view of the automobile’s environment, detecting ability dangers and supplying data to the ADAS machine to assist the driving force in keeping off injuries or collisions. Each sensor has its strengths and barriers, and ADAS systems frequently utilise multiple sensors to provide redundancy and enhance universal performance.

There are several sorts of sensors utilized in ADAS era. Here are the principle ones:

Radar
Uses radio waves to discover gadgets and measure their distance, velocity, and path of movement.
Lidar
Uses laser light to create a 3-D map of the vehicle’s surroundings, allowing for particular detection of items and their distance.
Camera
Uses optical sensors to seize photographs of the vehicle’s surroundings, providing records approximately lane markings, traffic signs, and other automobiles.
Ultrasonic
Uses excessive-frequency sound waves to stumble on objects and degree their distance.
Infrared
Uses warmth-sensitive sensors to detect gadgets, specifically in low-mild situations.
GPS
Uses satellite signals to determine the vehicle’s area, velocity, and path of motion, offering beneficial facts for navigation and site visitors control.

What are the unique ADAS functions?
There are many different ADAS features to be had in present day cars, each designed to improve driving safety and comfort. These ADAS features paintings collectively to decorate riding safety and convenience, offering drivers with treasured assistance and feedback to help them navigate the road thoroughly and correctly. New ADAS features are constantly being evolved and delivered to vehicles, representing an thrilling place of innovation within the automotive enterprise.

Here are some of the ADAS functions:

Adaptive Cruise Control
Imagine cruising at the surreal highways without having to worry about the vehicle in the front of you all at once slowing down. This is what Adaptive Cruise Control gives – a pressure-unfastened riding revel in by using adjusting the speed of your car and keeping a secure distance between your vehicle and the one in the front of you, ensuring you in no way tailgate or need to brake unexpectedly again.
Glare-Free High Beam and Pixel Light
If you’re using within the dark, the Glare-Free High Beam and Pixel Light technology facilitates optimise your headlights for optimum visibility. The glare-free excessive beam adjusts its beam to avoid shining at once into oncoming site visitors, whilst Pixel Light complements the best of light from your headlights, helping other avenue users see you.

This topic I will try to explain more in next part

Thank you

Diagnostic Development with AUTOSAR(Part-2)

smbalawad — Sun, 21 Jan 2024 11:42:49 +0000

Requirements Relating to a Tool Chain that Supports those
Processes
It must be possible to adapt tool chains used in the diagnostic development process to the above-mentioned scenarios. At the start of the process, it is necessary to define the diagnostic requirements in the Requirements Management System (RMS). From the diagnostic requirements, it is then possible to derive requirements for the application software and requirements for the associated diagnostic services. In general, the two types of requirements are implemented by different roles – in the form of software components as well as in the form of a suitable basic software configuration. They are then combined by the integrator
during ECU integration. This is exactly where the afore mentioned diagnostic mapping in DEXT comes into play. The overall process is illustrated in Figure 2.

Figure 2: Diagnostic technique between the OEM and Tier 1 provider

In a top-down process, the diagnostic application software is first developed, or existing software is re-used. The diagnostic input data is derived from the requirements and interface descriptions for the application software. This represents a major advantage compared to many existing processes in which the diagnostic data is adapted to the requirements and application software. This is often a very time-consuming manual harmonization task.At the same time the DEXT format is created, it is also necessary to create the ODX data. Generating ODX and DEXT data from a common source ensures that the diagnostic tester behavior matches the diagnostic software in the ECU

Example Based on a Tool Chain
Figure 3 illustrates the example of a tool chain for diagnostic development that meets these requirements using tools from Vector. It consists of the tools Prevision for requirements and system design, Candela Studio as the diagnostic authoring tool and DaVinci Configurator Pro for configuring the basic software. A diagnostic requirement is defined in Prevision at an early development stage. For example, this could be a requirement to provide an oil temperature sensor. For this sensor, the diagnostics should contain a service for reading the oil temperature, a service for overwriting the sensor value by means of I/O control as well as support for one or more possible DTCs that indicate a temperature sensor malfunction. The software component interfaces of the System Extract are derived from these requirements in arxml format. The software component interfaces also define the parameters for the diagnostic objects. In the example of the oil temperature sensor, a software component port provides the current temperature value and the port’s interface defines whether the measured value is a 16 or 32-bit value, together with the conversion formula and unit used. A software
component synchronization functionality specially developed for this workflow in Candela Studio then automatically uses this information to generate the appropriate diagnostic data for the following diagnostic elements:

Diagnostic Data Identifiers (DIDs) for Read, Write and
I/O-Control
Routine Control Identifiers (RIDs)
Events and DTCs

In our example, the diagnostic expert creates “ReadDataByIdentifier” diagnostic service in CANdelaStudio. This
contains a “Temperature” data element with an unsigned 16-bit value and a resolution of 0.1 Kelvin, a I/O-Control service with the same data element and a DTC indicating a sensor defect. The diagnostic expert also defines the identifier that is used to access the oil temperature in the diagnostic communication.
Additionally, CANdelaStudio stores the port at which the software component supplies the temperature and the diagnostic service that reads the data from this port. Using this statistics,CANdelaStudio is capable of export the DEXT format collectively with the diagnostic mapping. DaVinci Configurator Pro reads inside the DEXT layout and derives the configuration of the diagnostic basic software program modules from it. DaVinci Configurator Pro then generates the software component interface for the diagnostic basic software modules and connects it to the ports of the application software components – in a way which is compatible with the diagnostic mappings in the AUTOSAR DEXT.

Figure 2: Diagnostic workflow primarily based on the instance of a Vector device chain

Conclusion
The AUTOSAR Diagnostic Extract opens new possibilities in the field of diagnostic development. From the precise description of the data, including the derivation of the basic software configuration, through the distributed development of diagnostics at the OEM and Tier 1 supplier through to a top-down approach to the automatic integration of the diagnostic functions in the ECU. The Vector tool chain uses these capabilities and simultaneously ensures the synchronization of the ODX and DEXT data. AUTOSAR DEXT is used in both AUTOSAR platforms: initially developed for AUTOSAR Classic, it is also the only diagnostic description format in AUTOSAR Adaptive. The presented method can therefore also be used for the AUTOSAR Adaptive platform based development

Thank you

Diagnostic Development with AUTOSAR

smbalawad — Sun, 21 Jan 2024 07:56:04 +0000

Introduction
The Benefits for Vehicle Manufacturers and Suppliers
OEMs and Tier 1 providers make use of many exceptional strategies for the improvement of car diagnostics. Various trade codecs are used and the implemented gear are normally adapted to every agency’s particular process. At the very cutting-edge, issues begin going on while diagnostic descriptions must be exchanged with improvement companions and used in their tool chains. This is always a time-consuming mission – if certainly it's miles possible at all to alternate statistics without any loss of facts. The AUTOSAR Diagnostic Extract Template (DEXT) gives a completely new range of possibilities for diagnostic development. The basic software program modules which might be relevant for diagnostics may be configured uniformly throughout employer barriers, as an instance OEMs and Tier 1 providers, or in collaborations between OEMs. Tasks that were previously carried out by way of the integrator at the Tier 1 dealer can now be found out in a decentralized manner the use of DEXT

DEXT Compared to Other Diagnostic Data Formats
DEXT was initially published with AUTOSAR 4.2.1. In the early stage, the description of the data transported using UDS and the UDS fault memory were standardized. AUTOSAR 4.3.0 added corresponding extensions for OBD-II, WWH-OBD, FIM (AUTOSAR Function Inhibition Manager) and SAE J1939. Consequently, at this level of content, DEXT covers the configuration of all basic software modules for diagnostics that are supported in AUTOSAR. With DEXT, it is possible to describe not only the data transported using the respective protocol, but also the origin of the data in the ECU’s application software. Only if both types of information are available it is possible to fully configure the diagnostic basic software. The diagnostic protocol and, in particular, the description of the diagnostic services and data transfer on the network, are not described. On the other hand, ODX has established itself as the data format for generic diagnostic testers. ODX describes the diagnostic protocol as well as the data transported between the ECU and the tester, together with the way this data is interpreted in a diagnostic tester. The source of the data in the ECU is of no importance for its processing in the tester and is therefore not specified in ODX. Despite this, ODX might be used as initial configuration input, primarily describing the existence and structure of the diagnostic data on the network. However, the diagnostic data must be linked to the ECU application either manually, or by means of special process steps. The information gap between ODX and ECU software is at its greatest when it comes to the description of the fault memory. For example, the debouncing or displacement algorithms used for error detection are of fundamental importance for the basic software, whereas this information is completely lacking in ODX. To some extent, the huge differences between the vehicle manufacturers’ ODX authoring guidelines further complicate the possibility of exchanging ECU configurations. In practice, processes that use the AUTOSAR-ECUC format for data exchange and initial data in the basic software rarely reach their goal. The ECUC format changes frequently and is adapted with every new version of the standard. Primarily it is designed as an input format for the embedded software code generators. ECUC also permits manufacturer-specific extensions, thus making unsuitable as a neutral exchange format.

Figure 1: Elements of the AUTOSAR Diagnostic Extract

AUTOSAR DEXT has been mainly designed to meet the necessities concerning input statistics of the simple software program.
The main elements are (Figure 1):

Selection of the diagnostic services and associated
subservices for UDS, OBD, WWH-OBD and J1939
Fault path and fault memory
Diagnostic data elements and the associated packaging
Mapping of the diagnostic data elements to the application software
Function-inhibition (FiM)
The example below illustrates the advantages of the AUTOSAR Diagnostic Extract based on a Data Identifier (DID). The AUTOSAR metamodel formally defines how a DID should be modeled. Unlike in ODX, there is no freedom of interpretation here and therefore also no risk of misunderstandings during data exchange between tools. The existence of a DID is specified by the instance of a Diagnostic Data Identifier. This instance contains the 16-bit number of the DID which is required for UDS. In addition, this instance aggregates one or more data elements, with the name and type of the DID data being defined. For the purposes of data type modeling, AUTOSAR reuses the preexisting system template metamodel. The DID itself can be used in a diagnostic service by the service instances Diagnostic ReadDataBy Identifier, Diagnostic
WriteDataBy Identifier or DiagnosticIOControl by means of a reference to the Diagnostic DataIdentifier. This is all what is needed to define the configuration of a DID in the diagnostic basic software (BSW). However, the basic software must still interact with the application software in order to read, write, or overwrite the DID. That is why DEXT contains an additional element: diagnostic mapping. It describes the connections between the diagnostic elements in the basic software, such as routines,
DID data, events, and the software components (SWCs) of the application layer. To this end, the interfaces of the software components must be suitably modeled in a way that adheres to a modeling pattern defined in AUTOSAR. Various communication patterns exist to access a function call on a client/server interface or read/write data via a sender/receiver interface. In the past, integrators had to manually configure thousands of connections of this type between the ports in the basic software and the application software. When DEXT is used, this operation can be automated and performed at the OEM/Tier 1 supplier. Integrators take over the mapping rather than having to generate it manually themselves for a large number of different connections. This reduces the probability of error, while simultaneously saving time and increasing quality

Scenarios and Roles in Distributed Diagnostic Development
Currently, there are considerable differences between the diagnostic development processes that are used today. In addition to the tools and their exchange formats, there are major differences in the contribution of OEM and TIER1. In practice, all the possible variants can be found: from end-to-end design by the OEM through combined diagnostic development by the OEM and Tier 1 supplier and on to complete development performed exclusively by the Tier 1 supplier.
Table a provides an overview of typical diagnostic processes.

Table a: Diagnostic processes among the OEM and Tier 1 supplier

This topic will be try to explain more in the next part

Thank you

Introduction to AUTOSAR and its Effect on Automotive Software Architecture(part-5)

smbalawad — Mon, 25 Dec 2023 18:18:54 +0000

ECUC Parameter Model
The ECUC parameter model contains the module the statistics concerning the boxes, parameters, and references. It specifies the relationship among the packing containers and parameters that may be used by the configuration version to describe the module template facts. The top-degree structure of the ECUC parameter model is proven in Figure 1

 fig 1-ECUC parameter model

ECU Parameter Definition elegance (EcuParameterDefinition) collects all references to person module configuration definitions of AUTOSAR ECUC and defines a reference
relationship to the definition of numerous software program modules. Module Definition elegance (ModuleDef) defines ECUC parameters of one software module consisting of BSW, RTE, SWC.

ECUC Model
This step of the ECUC process is not precise by AUTOSAR. The templates are the maximum critical a part of this thesis which facilitates in automating the configuration system rather than manually configuring the BSW. Figure 3 suggests the magnificence diagram with the respective attributes. The structure is primarily based on the configuration metamodel. To assist the developer in growing a template, the model presents numerous auxiliary features. They are meant to facilitate get entry to to sure elements of the model. For example, the complete
configuration of a module ought to be returned via passing its call. It is distinguished among call and reference. The getByName feature searches for a particular call in
the model Uppercase and lowercase letters are taken into consideration. The feature getByRef makes use of a reference string to attain the referenced item. An example of a VALUE-REF tag with reference to the class diagram is proven in Figure 2 According to the magnificence diagram, we get the subsequent capabilities:
getModuleConfigurationByName
• getModuleConfigurationByRef
• getContainerByRef
• getValueByRef
• getArPackageByRef
• getValueByName
• getReferenceValueByValueRefName
• getReferenceValueByDefinitionRefName

fig 2-Value-Ref Structure

fig 3-Class Diagram representing generic module design in AUTOSAR
A certain description of those strategies may be determined within the next bankruptcy. In addition,
there are the usual getter functions for getting a category’s attribute. The setter functions are not implemented to exclude adjustments in values and to hold consistency

Module Configuration Template (MCT)
The BSW Module Configuration Template provides the template of the source code that ought to be generated. The values from the ECUC Description may be inserted into the template via the ECUC Model defined within the next bankruptcy. The template is written in Xtend programming language. The developer of the respective BSW Module is accountable to provide a template for the module configuration. Xtend is used to jot down the module
configuration templates due to its optimized syntax, it permits shorter and readable code and is well matched with Java. The MCT accesses the module values from the ECUC model and describes their characteristic in the ECU. APAG Elektronik affords a library with capabilities that can be used to access the values without increasing the complexity of the code. These capabilities are described in the subsequent chapter. Each template contains a version string. During execution, the version is passed as an argument (-v). Only if the transferred version suits to the template’s version, the technology might be finished. Further arguments are the route to ECUC Description (-ecuc) and the direction to the output (-o). Without these arguments, the generation received’t be commenced successfully. The Module Configuration Template needs to be compiled to an executable and stored with the naming
convention “«moduleName»_BswMCT.Jar”.

Automated Generation of ECU Configurations for
Watchdog Timer
This chapter describes the automated technology of ECUC for Watchdog Timer.The following sections describe the Watchdog Timer in AUTOSAR, implementation of the ECUC version, the module configuration templates and the Basic Software Source Code Generator (BSG) device

Watchdog Timer in AUTOSAR
In order to enable structured software development and to make certain desirable maintainability, extensibility, and portability of the software program, the whole Watchdog Timer module is advanced in keeping with a layer version such as three layers. The man or woman layers simplest communicate with each other through described interfaces. These interfaces contribute to the safety of the software program via preventing the character modules from being able to control any records in any way. In addition, an abstraction of the diverse layers is achieved, so a layer ought to (only) realize the interfaces to its superordinate or subordinate layer, whereby the complexity of the whole device is encapsulated.
The three watchdog
modules are:

Watchdog Driver Module
The Wdg Driver module affords services for initialization, changing the operation mode and setting the trigger situation (timeout). This module is used to at once manage
the hardware watchdog timer and manipulate its function. Table 4.1 indicates the Wdg module data with facts about the containers which can be present in it as special by
AUTOSAR [11]. Each of the boxes has parameters which are defined to perform obligations inside the Wdg Module.

Table 1-Wdg module-specific information

Watchdog Interface Module
In case of more than one watchdog tool and watchdog driving force (e.G. Each an internal software watchdog and an outside hardware watchdog) getting used on an ECU, WdgIf lets in the watchdog manager (or any other patron of the watchdog) to pick out the ideal watchdog motive force - and accordingly the watchdog tool - whilst keeping the API and capability of the underlying motive force. Table 2 shows the WdgIf module records with information approximately the boxes that are found in it as distinct by using AUTOSAR [11]. Each of the bins has parameters which are described to perform obligations within the WdgIf Module.

Table 2-WdgIf module specification information

This topic will be try to explain more in the next part

Thank you

Introduction to AUTOSAR and its Effect on Automotive Software Architecture(part-4)

smbalawad — Mon, 25 Dec 2023 17:07:27 +0000

Extract ECU-Specific Information
The tool AUTOSAR ECU Configuration Extractor (ex. System desk, Da-Vinci) extracts the data from the System Configuration Description wished for a particular ECU. This is a one to 1 reproduction of all factors of the System Configuration Description that are mapped to this specific ECU. The network database (ex CAN.Dbc) document is the enter to produce ECU extract ( .Arxml ).

Configure (BSW) ECU
The ECU configuration in particular offers with the configuration of the RTE and the Basic Software modules. The configuration is primarily based at the parameters which are available inside the ECU Extract of System Configuration. BSW additionally includes the Vendor-Specific ECU Configuration. This is vital due to the fact the output ECU Configuration Description has a bendy shape that does not define a fixed range of configuration parameters at the same time as ECU extract.
The conversation module, MCAL, the running gadget, or AUTOSAR services ought to be described during BSW configuration.

Generate Executable
After the ECU configuration is done, a software supply for numerous modules of the ECU may be generated. This refers to the Basic Software (e.G. Conversation module, operating machine, and so forth.), and the RTE.
The configuration, supply code technology and generate executable ECU code resemble today's improvement practice. This is specifically a linking of all additives. There are extra steps involved. E.G. Facts from the ECU Configuration Description is probably used to generate specifically configured executable software program.

SW-Component Implementation
The initial paintings of SWC begins with imparting the necessary components of the software program thing description [SWCTempl]. That is Component Internal Behaviour Description as a part of the software program thing associated templates. The inner behaviour describes the scheduling applicable elements of a thing, i.E. The runnable entities and the events they reply to. Furthermore, the behaviour specifies how a factor (or extra precisely which runnable) responds to events like obtained facts elements. However, it does now not describe the particular useful behaviour of the issue

Configuration Classes
The mission of compiling and linking is needed to create an executable (programmed binary), then the executable must be downloaded (flashed) to the hardware. AUTOSAR
specifies for these steps 3 distinct times for configuring a BSW module. The “precompile time”, “hyperlink time” and “publish-construct time”. Each of those instances has influences on the EcuC Description. The Pre-Compile Time Configuration, proven in Figure 1 is carried out earlier than the compilation.This can cause complete code sections can be excluded from the compiled configurations. The advantage that arises is this way memory area may be
stored, and capabilities will disappear from the compiled files. In order to make the capabilitiesto be had a recompilation of the code is vital.

fig 1-Pre-Compile time configuration chain

The Link Time Configuration is created throughout the link system. Figure 2.shows BSW module which includes two elements, the code, and the configuration. Both are compiled independently of every other. The item documents from the compilation procedure are connected collectively, which resolves present dependencies to external references. After the hyperlink system, the values of the configuration cannot be changed anymore

fig 2-Link Time configuration chain

Figure 3 shows the Post-Build Time Configuration. The module is already related and loaded on the ECU. At this point, the module will recognize the deal with where the
configuration may be discovered in reminiscence. One risk that this type of configuration entails is that there is no guarantee that this location in reminiscence has been flashed with an appropriate configuration, if there is a fault inside the process, it'll now not be detected until runtime. For the other configuration training, the compiler or linker can make certain that the configuration
exists. The benefit of this variant is that the values of the configuration can be modified by means of rewriting the reminiscence area. AUTOSAR distinguishes between two use cases inside the postbuild configuration. First, the previously described case proven in Figure 3 referred to as loadable configuration and 2nd, the selectable configuration, shown in Figure 4 The
20 technique is harking back to the link-time configuration but continues to be taken into consideration as submit-construct. This is because multiple configuration sets are provided at link time. During runtime, more specifically at the initialization of the ECU, one of the current configurations may be selected. Thus, it is able to be stated that the ECU is configured after building.

fig 3-Post-construct time loadable configuration chain

fig 4-Post-build time loadable configuration chain

Configuration Metamodel
AUTOSAR is based on Model Driven Architecture (MDA). It is a software program layout approach that makes use of models for the development of software systems. The model
specification is written the usage of Unified Modeling Language (UML). AUTOSAR is made up of numerous models which can be based on metamodels. One of these metamodels is known as the Configuration Metamodel. This metamodel describes the shape of the configuration version. It in particular includes containers and parameters. Containers are used to institution the parameters and they also can have sub-bins. The configuration version is used to keep
the configuration of the BSW, which corresponds to the BSW model cited inside the previous section. The goal of the metamodel is to make it viable to explain the AUTOSAR unique factors which include the configuration parameters with the same set of language factors. The configuration language generally uses boxes and parameters which describe the values which might be used to configure the ECU. The configuration metamodel is described in parts: ECUC parameter definition and ECUC description.

The ECUC description is written using a template to specify the layout alternate for the configuration values in the ECU. This template is written the usage of ARXML which was explained in one of the previous sections. The ECUC parameter description which is also an ARXML document includes the information on what type of regulations and capabilities are given to the parameters. The dating between the 2 is shown in Figure 5.

fig 5-Parameter definition and ECUC value files

This topic will be try to explain more in the next part

Thank you