Transaction returning ConcurrentTX as status not stopped
Opened this issue · 9 comments
Checklist
- I checked other issues already, but found no answer/solution
- I checked the documentation and wiki, but found no answer/solution
- I am running the latest version and the issue still occurs
- I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)
Specifications
SteVe Version : 3.6.0
Description
Starting several transactions with the same id tag end up having one transactions accepted and other concurrenttx but not stopped server side.
It can lead to a DoS by flagging all tags as used in never stopped transactions.
Steps to Reproduce the Problem
- use https://github.com/SAP/e-mobility-charging-stations-simulator
- start the ATG with one id tag
- watch the ever growing list of active transactions on steve web ui
this is by design. i addressed this point in various issues, here is one example.
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.
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.
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?
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.
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.
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).
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.
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?