DO-178B ve Gerekircilik (Determinizm)

Determinizm Nedir
Determinizm tanım olarak bir işin önceden belirlenmiş yasalara uygun olarak çalışması demek. Deterministic kelimesinin açıklaması şöyle.

"Deterministic" means "if you put the system in the same situation twice, it is guaranteed to make the same choice both times".

"Non-deterministic" means "not deterministic", or in other words, "if you put the system in the same situation twice, it might or might not make the same choice both times".

Stochastic
Determinizm'in tersi stochastic. Stochastic kelimesinin açıklaması şöyle. Yani belirsizlik/rastgelelik unsuru içeriyor

A model or process is stochastic if it has randomness. For example, if given the same inputs (independent variables, weights/parameters, hyperparameters, etc.), the model might produce different outputs. In deterministic models, the output is fully specified by the inputs to the model (independent variables, weights/parameters, hyperparameters, etc.), such that given the same inputs to the model, the outputs are identical.

Determinizm ve Real-Time

Açıklaması şöyle. Hard real-time ve soft real-time sistemlerin deterministic olması beklenir.

- Real-time: This is the marketing term. It can be anything from zero latency and zero spikes to minutes and beyond.alo

Hard real-time: Missing a deadline is a total system failure. Delays or spikes are not accepted. Hence, the goal is to ensure that all deadlines are met,

- Soft real-time: The usefulness of a result degrades after its deadline, thereby degrading the system’s quality of service. The goal becomes meeting a certain subset of deadlines to optimize some application-specific criteria. The particular criteria optimized depend on the application.

- Near real-time: Refers to the time delay introduced, by automated data processing or network transmission, between the occurrence of an event and the use of the processed data. The range goes from microseconds and milliseconds to seconds, minutes, and sometimes even hours or days.

Hard Real-time Nedir?

Hard Real-time Nedir? yazısına taşıdım

Soft real-time Nedir?

Açıklaması şöyle

Soft real-time is used for applications such as:

- Point-to-point messaging between IT applications

- Data ingestion from various data sources into one or more data sinks

- Data processing and data correlation (often called event streaming or event stream processing)

Response Time

Şeklen şöyle. Sistemde tepki/cevap süresi (response time) düşük önem sahip bir şey tarafından da engellenmemeli.

Determinizm'i Bozan Bazı Şeyler

1. Heap Kullanımı
Açıklaması şöyle

Usage of dynamic memory allocation can cause non-determinism, particularly if the program has a varying pattern of allocating, deallocating, and reallocating. The timing of allocations, deallocation, and reallocation can vary over time - and therefore making timings for the system as a whole unpredictable.

Çözüm olarak şu tarz bellek yöneticileri kullanılabilir.

Using a heap manager with non-deterministic behavior creates a program with non-deterministic behavior. But that is obvious.

Slightly less obvious is the existence of heap managers with deterministic behavior. Perhaps the most well-known example is the pool allocator. It has an array of N*M bytes, and an available[] mask of N bits. To allocate, it checks for the first available entry (bit test, O(N), deterministic upper bound). To deallocate, it sets the available bit (O(1)). malloc(X) will round up X to the next biggest value of M to choose the right pool.

This might not be very efficient, especially if your choices of N and M are too high. And if you choose too low, your program can fail. But the limits for N and M can be lower than for an equivalent program without dynamic memory allocation.

2. Önbellek
CPU ile gelen Önbellek (cache) ve Branch Prediction algoritmaları determinizmi bozuyor diye bazı projelerde bu özellikler kapatılıyor. Bir açıklama şöyle. Burada bazı istisnai durumlarda önbellek kullanımının nasıl bir yavaşlamaya sebep olabileceği anlatılıyor

If code accesses a piece of memory that had not been accessed in a long time and wasn't in a region of fast memory called the cache, the access would need to be performed using slow memory, but the data would get copied to the cache so that if it's needed again soon, it can be fetched more quickly--often more than an order of magnitude faster. Because the cache is much smaller than main memory, however, data which is in the cache but hasn't been used for awhile will often need to be displaced to make room for other data. Although it's unlikely, one may end up with situations where the CPU repeatedly selects for displacement information that's about to be used again. Fetching data from memory in a sequence that causes that to occur may take an order of magnitude longer than fetching that same data in a slightly different sequence.

3. Out Of Order Execution

Bu soru bazı eski nesil işlemcilerin gerçek zamanlı işler için niçin daha uygun olduğu sorulmuş. Verilen cevap şöyle. Aslında Out Of Order Execution yeteneği kapatılabilir mi bilmiyorum.

On a typical 6502, Z80, or 68000 system, it's possible to predict very precisely exactly how long a piece of code will take to execute. The same is true, incidentally, of many small microcontrollers produced today. In many cases, this allows some operations to be done more efficiently than would otherwise be possible.

...

On modern CPUs, out-of-order execution, memory caching, and many other features will improve the speed with which many operations are performed, most of the time, but predicting how much the speed will be improved would often be impractical.

Multicore Sistemler

Açıklaması şöyle. Burada Determinizmle ilgili bazı maddeler var. Özellikle koyu ile işaretli ikinci madde önemli

4 common challenges you’ll face when switching from a single core to a multicore system in your DO-178C project…

Multicore systems are of course much more complex than their single core counterparts.

To understand how to verify their timing behavior, we must first understand the unique challenges inherent in the analysis.

1)We need to consider resource contention and interference:

The execution time of a task in a multicore system is affected by contention for shared resources and the interference this causes. To investigate the timing behavior of a multicore system, we need to take this interference into account.

2) Multicore timing analysis can’t be entirely automated:

The complexity of multicore processors means that building a fully automated timing analysis solution is unrealistic. While tool support can automate most of the data gathering and analysis processes, engineering wisdom and expertise is needed to understand the system and direct tool usage to produce necessary evidence.

3) We have to test on the real hardware:

Multicore CPUs are complex and often their internals are hidden, making purely analytical models of limited use in understanding their timing behavior. As such, the only way to determine exactly how the processor and its components behave is to measure timing behavior on the system itself.

4) Assumptions need to be tested:

To analyze the timing behavior of a multicore system, you will need to make some assumptions about things such as the interference channels in the system and their effects. After running tests based on these assumptions, you will likely need to reassess those assumptions and rerun tests.

Bir başka açıklama şöyle

How do you approach the use of multicore processors in avionics?

Let’s take a look at the issue of interference channels.

But first some context….

Multicore processors (MCPs) are increasingly used within avionics systems, and this trend is likely to continue.

These processors offer increased performance compared to single core processors and allow more functionality to be included within hardware.

They can also contain other embedded functions such as memory management and embedded security, reducing the chip count for a system.

Furthermore, as single-core processors are used in so few other industries, their future supply is a serious concern for avionics suppliers.

Whilst MCPs offer a great deal of advantages, their behavior is harder to verify due to the presence of interference channels.

Of these interference channels, interference caused by the sharing of certain resources in multicore systems is one of the most significant in terms of execution times.

Interference based on shared resources may occur in multicore systems when multiple cores simultaneously compete for use of shared resources such as buses, caches and main memory.

Rapita’s solutions for multicore timing analysis analyze the effects of this type of interference channel.

A very simple example of a shared resource interference channel is shown on the post image.

In this simplified example, tasks running independently on the two cores may need to access main memory simultaneously via the memory controller.

These accesses can interfere with each other, potentially degrading system performance.

Robust partitioning Ne Demek

Açıklaması şöyle

Two types of partitioning exist: 

1. space (or resource) partitioning, where partitioned components are isolated by operating on different hardware devices or different regions in a single device, 

2. time partitioning, where partitioned components are isolated by operating in non-overlapping time periods (time slices).

 

Both types of isolation are well understood for single core systems and are implemented in many real-time operating systems used in the aerospace domain through the use of scheduling architectures such as ARINC 653.

The most rigorous separation is termed robust partitioning.

This is defined for single core systems in the ARINC 653 standard, where it refers to complete isolation of separated components, i.e. the execution of one component can have no effect on the other.

To put this another way, the execution time of each thread is completely free from interference by the other threads 

Most of the technology for partitioning of single core systems also applies to multicore systems...