WIP: CPA in Prosa

This is ongoing work with @sophie and @borni on adding CPA to Prosa.

We are currently working on adding basic definitions and the specification of the analysis.

For now we have (partially) ported definitions related to priorities and arrival curves since we depend on these definitions.

This is still a draft.

We aim to merge this early next week which will involve porting:

• definitions about task_arrivals
• arrival curve model
• FPP scheduling policy
• definitions related to busy intervals

This should be rebased on !27 (merged)

Why does the notion of a busy interval depend on ideal schedules? Can this not be defined for uniprocessor schedules in general?

General question: why should there be a busy window file in the CPA directory? Do we need a new busy window file for every analysis, or can we have a central, shared busy window concept?

From the discussions in Braunschweig, I gathered that CPA is specifically not just busy-window analysis, and that in fact the CPA framework can be instantiated also with analyses that do not rely on the busy-window approach. Including a busy window def in the CPA directory seems somewhat contradictory then.

Note also that Sergey (CC: @sbozhko) recently added a general notion of busy windows. Unless there are specific reasons not to, I'd suggest that we leverage Sergey's work in the restructured version of Prosa. (We have a paper on this work under submission, ping me if you'd like to get a copy.)

added 5 commits

• a9c185ed...03863f8f - 2 commits from branch master
• 29ee6900 - Definitions for CPA
• ceb2e0d2 - arrival curves + work on curve propagation
• 979e823c - Fix after rebase

Compare with previous version

added 1 commit

• 38d62d7f - temp commit

Compare with previous version

added 1 commit

• 884acafc - path response time

Compare with previous version

added 1 commit

• 7402986e - safety first

Compare with previous version

added 1 commit

• 12f44b28 - functional chains

Compare with previous version

added 1 commit

• d8fb7bfc - fixes

Compare with previous version

Quick update: There is ongoing work with Jonathan (summer intern at INRIA grenoble) to prove similar results for CPA based on the periodic with jitter model.

We have started from scratch, drawing inspiration from the definitions in this branch. When we are ready to merge something we will delete this merge request and replace it with a new one.

unassigned @bbb

Can this MR be closed or is it still required to keep track of something? If there's something to keep track of, should this MR be converted into a ticket? You can of course always create a new MR.

You can close this, we will open separate merge requests as we integrate the building blocks of CPA.

closed