Comments (9)
this is by design. i addressed this point in various issues, here is one example.
from steve.
an excerpt from another msg:
however, all these possibilities assume steve to be a tight controller and gatekeeper for the sake of security. there is a tone in spec that offline behaviour of stations is as important as online behaviour. therefore, all these StartTransactions and StopTransactions can/should be treated as "happenings/events of the past being reported to backend". this diminishes the role of the backend, and we cannot be as tight as you would like. the station must do the right thing.
from steve.
The transaction lifecycle should be a state machine hindering duplicate transactions on the same EVSE to stay opened on the CSMS side.
Once its modeled as a state machine, if one transaction on a EVSE has never reached its final state but the EVSE has started a different transaction then it's safe to soft stop any transactions not in the final state state on it.
A soft stop is a simulation of a stop transaction using the latest transaction metervalues to compute the meterstop. The transaction in soft stop state can be put in stop state if a stop transaction is received later on.
The current design at transaction lifecycle handling is too fragile and require needlessly manual housekeeping of the transactions.
from steve.
steve already has the functionality of what you call "soft stop", which the user has to do manually in GUI because i didn't enforce this globally.
what is your suggestion? to automate this soft stop?
this is a workaround with heuristics to make the decision about stop values. this decision might be lossy/wrong: what if some messages (i.e. metervalues) were delayed and therefore the steve is not up-to-date with the latest info, and therefore ends this tx with wrong values? or, what if StopTransaction of the previous tx was delayed, and steve wrongly (i.e. false positive) ended that even though StopTransaction would have arrived later?
from steve.
steve already has the functionality of what you call "soft stop", which the user has to do manually in GUI because i didn't enforce this globally.
what is your suggestion? to automate this soft stop?
The suggestion was to make the transaction lifecycle a state machine, like in OCPP 2 specs.
Why? because a state machine properly implemented on a critical core process will permit to automate decision safely at:
- handling OCPP messages related to a transaction
- catching issues with the transaction lifecyle and report them with detailed information
Since Java is probably offering state machine libraries, it will probably end up make the code cleaner with conditions at state transition expressed in a central abstraction.
this is a workaround with heuristics to make the decision about stop values. this decision might be lossy/wrong: what if some messages (i.e. metervalues) were delayed and therefore the steve is not up-to-date with the latest info, and therefore ends this tx with wrong values? or, what if StopTransaction of the previous tx was delayed, and steve wrongly (i.e. false positive) ended that even though StopTransaction would have arrived later?
A transaction lifecycle modeled against a state machine is able to deal with all of them:
- MeterValues out of order: the state machine is able to track if the transaction end MeterValues match the meterStop with an intermediate state with transition conditions (metervalues end missing / stop)
- StopTransaction not received and StartTransaction issued on the same connector: another state machine intermediate state with transitions conditions (soft stop)
- ...
Once the state machine model capture and implement a transaction lifecyle with all possible states and transition conditions, it becomes more easy to automate actions in a robust way, even as tunables disabled by defaults.
To summarize:
- Automating the "soft stop" or "user stop" behavior with a tunable with the current implementation is possible but will expose more issues than it solves. So I would not recommend it. Or implemented with big fat warning at enablement.
- Automating the "soft stop" or "user stop" behavior in a safe way will require a lot of work. But I think the effort worth it since it's a core critical process and OCPP 2 is already specifying transactions as state machines.
from steve.
i think you are focusing too much on a technicality (i.e. state machines) but not much on the business side. state machine is a just a model of real world states, transitions and conditions how to transition from a state to the next. if the conditions are blurry (which is my claim), it does not save us in that regard.
my questions were about the business flows (i.e. what workarounds to apply and how) and how to eliminate operational deadlocks. if the charging station is not sending some information (e.g. meter values, stop transaction), steve's workarounds and derived actions will be wrong. and therefore, your arguments in
A transaction lifecycle modeled against a state machine is able to deal with all of them:
- MeterValues out of order: the state machine is able to track if the transaction end MeterValues match the meterStop with an intermediate state with transition conditions (metervalues end missing / stop)
- StopTransaction not received and StartTransaction issued on the same connector: another state machine intermediate state with transitions conditions (soft stop)
are not addressing my aforementioned concerns. but hey, this is open source, i would welcome your contribution in a PR and have no problem at the end admitting i am wrong if i am wrong, as long as the final product will be better.
from steve.
i think you are focusing too much on a technicality (i.e. state machines) but not much on the business side. state machine is a just a model of real world states, transitions and conditions how to transition from a state to the next. if the conditions are blurry (which is my claim), it does not save us in that regard.
business model, workflows, ... can all be modeled as state machines with a deterministic behavior:
- Finite number of states
- Finite number of transition conditions
It's not a claim or an opinion, it's a proven theoretical fact in discrete mathematics. The transaction lifecycle does not have blurry transition conditions set since it's not an infinite set and can modeled by a discrete (hence deterministic) state machine: WS connection states and transitions are finite, connector states and transitions are finite, OCPP messages states are finite, etc. (the whole underlying system is using discrete sets of states and transitions conditions)
How complex is the resulting state machine model for transaction lifecycle?
- Less than 10 states
- More then 20 transition conditions
(Already done and implemented in proprietary code)
How complex is the code implementing it? less complex than the initial code with ugly hacks in various code path checking for OCPP message status, charging station connector status, WS connection status, connector status and consolidated in a unique place. The reporting on transaction is more clear in dashboard and logs.
Overhead?
Memory mainly
The topic is not about: Can a state machine model transaction lifecycle deterministically? The answer is already known. (just like Can finite automata a model regular expression? Can non deterministic finite automata model a programming langage syntax? ...). The questions are: is there alternative model less costly? does the effort worth it? is the state machine model complete (probably not, human make mistakes at modelling)? can we live without modeling it as state machine (less complex system such as TCP connection states is implemented without formal state machine, but complex one cannot)? ...
In the end, I would like to orient the discussion on 'how to make the transaction lifecyle more robust?' State machine usage is one known to work answer (hope my previous explanations make it crystal clear).
from steve.
thank you for the lecture on state machines... even though i know them quite well myself and implemented them professionally before.
as i said, feel free to contribute to the project. it would be a welcome enhancement.
from steve.
as i said, feel free to contribute to the project. it would be a welcome enhancement.
Since it's not a simple bug fix, but something needing a design document open to discussion, review: does the project use RFC in its workflow for features? How are usually elaborated features design?
from steve.
Related Issues (20)
- Why do I get 404 when I access static resources locally? Answer when you have time, thank you!
- Date handling in OCPP operations HOT 3
- Network requirement question HOT 2
- Connect charging station to Steve. HOT 2
- Multiple Webusers login HOT 6
- Use PKs for cross-referencing instead of business/natural keys HOT 6
- Installation fails on "Access denied" error HOT 3
- When i am trying to run the steve.jar file, i am getting below mentioned error: HOT 2
- Logs are Unavailable HOT 3
- New install - 0.7.7 - update schema update failed - Cannot change column 'chargeBoxId': used in a foreign key constraint HOT 3
- Transaction detail page should only show relevant meter values HOT 1
- Jooq warning in logs about using Converter with org.joda.time.DateTime
- Redirect to originally requested page after succesful login HOT 1
- Connection Issues with MicroOcppSimulator and SteVe Using Docker HOT 10
- Enhanced User Management and Functions for Steve HOT 7
- Validate chargeBoxId for WS connections HOT 4
- Encode values properly when rendering HTML pages
- Mark the most recent release as latest HOT 1
- Store Web API key in database -> Switch to basic auth HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from steve.