Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
R
racr-mquat
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Deploy
Releases
Model registry
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
René Schöne
racr-mquat
Wiki
Test scenario
Changes
Page history
New page
Templates
Clone repository
Test scenario for generation of ILP.
authored
10 years ago
by
René Schöne
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
Test-scenario.md
+26
-0
26 additions, 0 deletions
Test-scenario.md
with
26 additions
and
0 deletions
Test-scenario.md
0 → 100644
View page @
59938950
# Evaluating the generation of an ILP using RACR
## Setup
-
the initial system state is a generated system using the following parameters
-
`num-pe`
– total number of hardware resources
-
`num-pe-subs`
– number of subresources per resource (i.e. breadth of the HW-tree)
-
`num-comp`
– number of SW components
-
`impl-per-comp`
– number of implementations per component
-
`mode-per-impl`
– number of modes per implementation
-
possible other, not implemented possibilities to describe the system include
-
randomness for number of Impls and Modes
-
minima and maxima for properties
## Test
1.
create the initial system state, i.e. the example ast
`ea`
2.
`(att-value 'to-ilp ea)`
– generate the ILP, and measure the time for generation
3.
optional: solve the ILP and measure the time for solving
4.
change some hardware resources, i.e. do a rewrite of some terminales representing the values inside
the provision clauses of the respective resources
5.
GOTO 2.
Instead of changing the hardware, changing the software is also feasible, e.g. to simulate
new components or contract runtime feedback. The latter example means, that a contract is
re-calculated after the (monitored) execution of a component and its values are updated.
This diff is collapsed.
Click to expand it.