escet merge requestshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests2021-03-18T08:45:54Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/23Draft: Resolve "Improve installation instructions for macOS"2021-03-18T08:45:54ZBert Van BeekDraft: Resolve "Improve installation instructions for macOS"Closes #21Closes #21v0.1https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/38Draft: Resolve "Allow just last year in license headers"2021-04-19T12:37:46ZDennis HendriksDraft: Resolve "Allow just last year in license headers"Closes #64Closes #64v0.2Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/122#150, #144 Add warning message for event not enabled in controlled state spac...2021-08-31T08:19:49ZFerdie Reijnen#150, #144 Add warning message for event not enabled in controlled state space and changed simplificating for those eventsCloses #150
Closes #144Closes #150
Closes #144v0.3https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/255Draft: #111 Generate railroad diagrams during build rather than committing th...2022-01-19T17:12:30ZFerdie ReijnenDraft: #111 Generate railroad diagrams during build rather than committing them to Git repoCloses #111Closes #111v0.5https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/257Draft: Resolve "Railroad diagrams should not use `java.awt` drawing functiona...2022-01-21T07:00:28ZAlbert HofkampDraft: Resolve "Railroad diagrams should not use `java.awt` drawing functionality for graphics"Closes #293Closes #293v0.5Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/270Draft: #307 Add CIF to CIF transformation to anonymize names2022-02-25T14:55:31ZDennis HendriksDraft: #307 Add CIF to CIF transformation to anonymize namesCloses #306Closes #306Dennis HendriksDennis Hendrikshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/256#111 Generate railroad diagrams during build rather than commiting them to gi...2022-03-19T11:03:24ZFerdie Reijnen#111 Generate railroad diagrams during build rather than commiting them to git repo.Closes #111Closes #111v0.5https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/298#332 Manual target platform, activate by Oomph, incl Maven API/annos.2022-04-07T09:14:52ZDennis Hendriks#332 Manual target platform, activate by Oomph, incl Maven API/annos.See also the following discussions of issue #332:
* https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/332#note_665134
* https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/332#note_667078
I'm only creating this merge request t...See also the following discussions of issue #332:
* https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/332#note_665134
* https://gitlab.eclipse.org/eclipse/escet/escet/-/issues/332#note_667078
I'm only creating this merge request to archive this attempt. I'll immediately close it, as this is not the way to go for this particular issue.v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/271Draft: #316 Introduce small common position class in scanning and parsing2022-04-10T10:04:17ZAlbert HofkampDraft: #316 Introduce small common position class in scanning and parsingTo avoid a forced connection between parsing a text file and having to import EMF, a very simple `CommonPosition` class is introduced without additional dependencies if so desired.
I have no errors, and I can build it locally.
The numbe...To avoid a forced connection between parsing a text file and having to import EMF, a very simple `CommonPosition` class is introduced without additional dependencies if so desired.
I have no errors, and I can build it locally.
The number of files that it touches is somewhat insane, but changes are generally easy.
A perhaps somewhat tricky part is whether I made the switch from `CommonPosition` to `Position` always at the right spot. At times I made life easy by adding an overload to a commonly called function, such as error reporting.
What may be incomplete are the manifest dependencies of some plugins, perhaps some `position.metamodel` bundle imports are no longer required.
Closes #316v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/304#311 Consider warning for /disallowing plant referencing requirements in CIF2022-04-16T10:42:20ZFerdie Reijnen#311 Consider warning for /disallowing plant referencing requirements in CIFAddresses #311
It adds a warning for plant invariants that are defined in requirement automata.
It does **not** add a warning for referencing parts of a requirement in a plant automaton or plant invariant.Addresses #311
It adds a warning for plant invariants that are defined in requirement automata.
It does **not** add a warning for referencing parts of a requirement in a plant automaton or plant invariant.v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/278#271 Add asciidoc file checker2022-04-17T09:48:26ZAlbert Hofkamp#271 Add asciidoc file checkerApplication that performs a few additional checks on asciidoc files.
Addresses #271Application that performs a few additional checks on asciidoc files.
Addresses #271v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/294Draft: #344 Add Design Structure Matrix (DSM) clustering2022-05-09T07:42:17ZAlbert HofkampDraft: #344 Add Design Structure Matrix (DSM) clusteringDSM clustering is a stepping stone in multilevel synthesis ( #318 ), yet is also useful on its own.
For this reason I added the application as well. We apparently have no common tools documentation so I created a project for it, not sure...DSM clustering is a stepping stone in multilevel synthesis ( #318 ), yet is also useful on its own.
For this reason I added the application as well. We apparently have no common tools documentation so I created a project for it, not sure if that is sane at all, nor do I know what files to add and changes to add.
Closes #344v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/327#196 Add DCSH variable ordering algorithm to data-based synthesis.2022-06-27T19:51:45ZDennis Hendriks#196 Add DCSH variable ordering algorithm to data-based synthesis.Variable ordering changes/additions:
- Prepared `VarOrdererHelper` for more metrics besides total span.
- Reduced space used for printing total span metric.
- Variable amount of space based on initial metric value.
- Added WES to `Va...Variable ordering changes/additions:
- Prepared `VarOrdererHelper` for more metrics besides total span.
- Reduced space used for printing total span metric.
- Variable amount of space based on initial metric value.
- Added WES to `VarOrdererHelper` as additional variable ordering metric.
Graph related additions:
- Added `Graph` and `Node` classes to represent graphs for data-based synthesis variable ordering algorithms to use.
- Added graph representation support to `VarOrdererHelper`.
- For now, graphs are created from the existing hyper-edges, ensuring consistency between the different representations.
- We could later opt for other ways to create the hyper-edges/graphs.
- Added extra utility methods for use by variable ordering algorithms.
- Updated `CifToSynthesisConverter` for the added graph representation.
DCSH algorithm related additions:
- Added rooted level structure constructor for graphs.
- Added pseudo-peripheral node finder algorithms.
- I tried to stay as close as possible to the original papers.
- We have multiple algorithms here.
- These are the ones which are needed for the node ordering heuristic algorithms.
- We could experiment later which ones work best. (see below)
- For now, node ordering algorithms use the ones from their corresponding papers.
- Added node ordering heuristic algorithms.
- I tried to stay as close as possible to the original papers.
- These are the ones we need for the DCSH variable ordering algorithm.
- Weighted Cuthill-McKee has been improved wrt the original paper: it works also for multiple unconnected partitions with >1 node.
- Added variable ordering algorithms.
- Added Sloan and Weighted Cuthill-McKee variable ordering algorithms, using the corresponding node ordering algorithms.
- Added 'choice' and 'reverse' wrapper variable ordering algorithms.
- Add DCSH variable ordering algorithm.
- Is for now based on graphs constructed from the existing hyper-edges, ensuring consistency between the different representtations.
- Could later create DMSs/hyper-edges based on the paper's approach.
Data-based synthesis tool additions:
- Added new option for enabling DCSH variable ordering.
- Is disabled by default, as I consider it experimental for now.
- The 'experimental' label here is for end users. It does not concern the implementation.
Data-based synthesis variable ordering documentation additions/changes:
- Added DCSH algorithm/option.
- Extended explanation of heuristic algorithms in general.
- Extended explanation of when algorithms are not applied.
- Extended descriptions of the FORCE and sliding window algorithms.
Data-based synthesis tests additions/changes:
- Renamed data-based synthesis test cases relating to `force`.
- The `force` tests were about FORCE and sliding window, so were wrongly named.
- Changed `_force_` to `_algos_`.
- Also extracted the related common options in the test ToolDef script to variables.
- Added DCSH to variable ordering integration tests, to be applied with all the other algorithms for the `algos` tests.
- Resulting metrics are the same or better for all these tests with DCSH added to it.
- Added single variable ordering algorithm integration tests, besides the ones that test all the algorithms at once.
- But only for a single initial random order, not for all the other initial orders, to avoid an explosion of tests.
Regarding reviewing:
- I tried to keep the stack of commits reviewable one by one, although there are a few fixes/changes at the end that could potentially have been integrated into earlier commits.
- Still, reviewing this per commit can be useful, as otherwise the totality of changes can be overwhelming, and the commits build towards the end result nicely.
I stopped here with this branch, as it is quite extensive already. The following are left as future work. I've created issues for the most relevant ones:
- #375 It would be good to have some scripts to benchmark the benchmark models, comparing for instance FORCE + sliding window against DCSH + FORCE + sliding window, in an automated fashion. I partly put something together for this already.
- #376 I think more testing is needed. I don't yet know whether the improvements we get in terms of better variable orderings and reduced synthesis effort match what the DCSH paper indicates. That would be good to check before lifting the 'experimental' label for end users to use it.
- The choice variable orderer could support reverse orders as well, natively, to avoid applying the algorithms twice. However, that leads to more code, and a less modular design. I hope execution times are very short already anyway. But, I still want to measure those times to be sure. Otherwise we may want to look into this optimization.
- #374 I found that our `product-escet` launch configuration is configured with only 4 GB of memory. That seems very low for todays systems.
- #377 Hyper-edge creation has a bug, where for location invariants actually the component invariants are used. I'm a bit hesitant to change this now though, as it makes comparing the performance of DCSH against the paper more difficult. Also, what if it reduces synthesis performance. We have no good benchmarking set yet to test this.
- #378 Data-based synthesis now only allows DCSH to be applied before FORCE and FORCE before sliding window. The order is fixed. I think the options should be generalized, to allow for instance `choice(dcsh, sequence(force, sliding-window(9)))` etc. This gives more flexibility for testing different configurations. Actual testing would require more benchmark models though.
- #379 There are several places where choices can be made. We can choose the current hyper-edges vs the ones defined in the DCSH paper. We can enable DCSH by default or not. We can choose per algorithm (DCSH, FORCE, sliding window), to base it on the total span or WES metric. For the node ordering algorithms, we can choose which pseudo-peripheral node finding algorithm to use. All of this requires that we can determine what is better, hence we need ways to specify these choices, scripts to easily test the differences, and enough benchmarking models to conclude what is really better in general.
- Variable ordering seems to lack cancellation checking. If the code runs for longer times (see other point), then we may need to add more of it. For now, this does not seem needed.
- #380 We currently use the original hyper-edges. We could implement the hyper-edges defined in the DCSH paper, which may perform better.
Closes #196v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/283Draft: #176 Upgrade to Eclipse 2022-032022-08-08T06:59:47ZFerdie ReijnenDraft: #176 Upgrade to Eclipse 2022-03Closes #176 #76Closes #176 #76v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/352Draft: #382 Make plcgen0 accessible in ESCET.2022-08-11T10:50:09ZAlbert HofkampDraft: #382 Make plcgen0 accessible in ESCET.Making previous art available for testing and reference.
An improved version is being created in #397.
## Restrictions:
``` text
// 1. no external functions
// 2. no tau events
// 3. no types: Set, Func, Comp...Making previous art available for testing and reference.
An improved version is being created in #397.
## Restrictions:
``` text
// 1. no external functions
// 2. no tau events
// 3. no types: Set, Func, CompParamWrap, CompInstWrap, ComponentDef, Dist, Dict, Void.
// 4. no automaton reference (or self) child isn't allowed
// 5. no exprs: slice, tau, event, set, time, self, component, compParamWrap, compInstWrap, dict
// 6. no urgent locations/edges
// 7. must have trivially true initial location and expressions.
// 8. no empty lists/arrays
// 9. no variable length lists
// 10. no continue function statement (from FuncGen.java:186, even though funcs are not allowed)
// 11. no function parameter names that are are keywords, including EN and ENO. (from renameNames:393)
// 12. no string projection
// 13. no multiple initial values
// 14. no stdLibFuncs: ACOSH ASINH ATANH BERNOULLI BETA BINOMIAL CEIL CONSTANT COSH DELETE EMPTY ERLANG EXPONENTIAL FLOOR FORMAT GAMMA GEOMETRIC LOG_NORMAL NORMAL POISSON POP RANDOM ROUND SCALE SIGN SINH SIZE TANH TRIANGLE UNIFORM WEIBULL
// 15. no unary expression SAMPLE
// 16. no binary expression ELEMENT_OF SUBSET
// 17. no internal functions with cyclic dependencies (there should not be functions)
// 18. no an event must have at least one non-monitoring automaton. (-> finite response)
// 19. no list/array of empty tuples
// 20. no constants may not use functions (both internal and stdlib).
```
CIF code that will cause crashes/incorrect PLC code:
``` text
- Using tuples in updates creates incorrect PLC code, eg "edge a do x:=(1,2);"
- Events that are declared within an automaton but not used anywhere result in an AssertionError.
- Multi-assignments result in a java.lang.NullPointerException. eg "edge a do (x,y) := (y,x);"
```
## Using the generator:
- Make an empty IO table named `empty.csv`.
- Make a `.tooldef` file with the following text:
``` tooldef
// Defines the 'plcgen0 tool.
tool int plcgen0(list string args = [], string stdin = "-", string stdout = "-", string stderr = "-",
bool appendOut = false, bool appendErr = false, bool errToOut = false, bool ignoreNonZeroExitCode = false):
return app("org.eclipse.escet.cif.plcgen0", "org.eclipse.escet.cif.plcgen0.app.PlcGen2App", args, stdin, stdout, stderr,
appendOut, appendErr, errToOut, ignoreNonZeroExitCode);
end
// Run the plcgen0 program.
// - Replace "abb" by "siemens-7-1500" to get siemens output, (Other targets will likely fail.)
// - Replace "model.cif" by the name of the cif model to convert,
// - stdout and stderr settings may be omitted to get the output at the console.
plcgen0(["--io-table=empty.csv", "--target-type=abb", "model.cif"], stdout="out_file", stderr="err_file");
// For a non-empty IO table, the following fields are required for each line in the .CSV file:
// - PLC address,
// - PLC typename,
// - Full path to CIF input-variable or output location/disc-variable/alg-variable
//
// For example for "input bool input1" and "alg bool output1 = ..." in the root of the specification, the following is accepted.
// %I1,BOOLEAN,input1
// %Q2,BOOLEAN,output1
```
- Adjust the `plcgen0` line to your liking, `plcgen0(["-h"]);` will dump the accepted options.https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/320Draft: #368 Implement `cif2dsm` computation2022-08-17T11:43:12ZAlbert HofkampDraft: #368 Implement `cif2dsm` computationCloses #368Closes #368v0.7Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/164#199 Open large CIF files with standard text editor, not CIF editor2022-10-17T19:47:25ZDennis Hendriks#199 Open large CIF files with standard text editor, not CIF editorCloses #199Closes #199v0.4https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/431#359 Attempt to upgrade to Tycho 32022-12-04T16:35:19ZDennis Hendriks#359 Attempt to upgrade to Tycho 3I'm creating this merge request only to preserve the effort this branch. I'll close this merge request immediately, as we can't actually upgrade to Tycho 3. When we upgrade to Tycho 4, we should look at this merge request again.
Address...I'm creating this merge request only to preserve the effort this branch. I'll close this merge request immediately, as we can't actually upgrade to Tycho 3. When we upgrade to Tycho 4, we should look at this merge request again.
Addresses #359v0.8https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/399#424 Generalize allowed invariants check.2022-12-07T12:19:19ZAlbert Hofkamp#424 Generalize allowed invariants check.Addresses #424
Just supervisor kind checking for invariants wasn't sufficient for cif2plc, so generalized the invariants check to place, supervisor kind and invariant kind.Addresses #424
Just supervisor kind checking for invariants wasn't sufficient for cif2plc, so generalized the invariants check to place, supervisor kind and invariant kind.Albert HofkampAlbert Hofkamphttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/462Draft: #488 Search engine indexes old versions2023-01-05T11:42:52ZFerdie ReijnenDraft: #488 Search engine indexes old versionsAddresses #488.Addresses #488.