[OASIS Issue Tracker] (OCPP-12) Write CR proposal to address how to handle large amounts of queued messages.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OCPP-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64377#comment-64377 ] 

Reinier Lamers commented on OCPP-12:
------------------------------------

Jonel, the issue I was thinking of is about queuing transaction-related messages, which OCPP 1.x forces charge points to do, leading to problems for us. I'm not sure if that's what you mean by this description, or if I should create a separate issue for that.

For the transaction issue, there are two use cases:

1. As a charge point operator, I want to be sure at  some point that I received all messages about a transaction, so I can assign a price to it based on the complete transaction information

2. As a charge point operator, I want to receive transaction-related messages as soon as possible, so I know in real-time who is charging at which charge point

OCPP solves (1) by requiring charge points to send transaction-related messages strictly in order, so that at the moment the charge point operator receives a StopTransaction, it knows that it has received _all_ messages about that transaction.

This solution however causes trouble for (2). If delivery of one transaction-related message fails, the charge point cannot send later messages. Then we don't know who is charging on that charge point.

Note that failure is always possible. Even in a fairytale world in which the Central System and Charge Point code are free of bugs and misunderstandings, bugs in pieces of software outside of the operator's direct control can have bugs causing message delivery failures. Think of JSON parsers, auto-generated SOAP code, proxy servers, etc.

There are a bunch of solutions we have thought of already:

1. allow charge points to skip failed messages after a number of attempts. This has been included in OCPP 1.6.

2. explicitly make the Central System instruct the charge point to skip the message at the head of the queue

3. put information on the charge card identifier in status notification messages, so the charge point can tell the Central System who is charging even when queuing transaction messages

And then there is a proposal 4 that I like best: including per-transaction sequence numbers in transaction-related messages. The Central System can then check that no sequence numbers are missing before settling a transaction, and be sure that its information is complete without forcing the charge point to queue anything. So a message exchange about a transaction could look lik:

> TransactionStarted.req(seqNo=1, meter = 2345, idTag="ABCDEF010203", ...)
< TransactionStarted.conf.conf(transactionId=7, ...)
> MeterValues.req(transactionId = 7, seqNo=2, value=2347, ...)
< MeterValues.conf()
> MeterValues.req(transactionId = 7, seqNo=3, value=2349, ...)
< MeterValues.conf()
> TransactionStopped.req(transactionId = 7, seqNo = 4, meter=2350, ...)
< TransactionStopped.conf(...)

Now the Central System can check that it has a series of transaction-related messages for transaction 7 with incrementing sequence numbers. If it gets for instance this series of transaction-related messages instead:


> TransactionStarted.req(seqNo=1, meter = 2345, idTag="ABCDEF010203", ...)
< TransactionStarted.conf(transactionId=7, ...)
> MeterValues.req(transactionId = 7, seqNo=2, value=2347, ...)
< MeterValues.conf()
> MeterValues.req(transactionId = 7, seqNo=4, value=2349, ...)
< MeterValues.conf()
> TransactionStopped.req(transactionId = 7, seqNo = 5, meter=2350, ...)
< TransactionStopped.conf(...)

The Central System can see that the sequence number 3 is missing, and there must be one more MeterValues request that it didn't receive yet. The Central System can then wait for that message before it finally settles the transaction with transactionId 7. 


> Write CR proposal to address how to handle large amounts of queued messages.
> ----------------------------------------------------------------------------
>
>                 Key: OCPP-12
>                 URL: https://issues.oasis-open.org/browse/OCPP-12
>             Project: OASIS OCPP Electric Vehicle Charging Equipment Data Exchange TC
>          Issue Type: Task
>         Environment: 2.0 RC 2 (old version) improvements
>            Reporter: Jonel Timbergen
>            Assignee: Li Sibo
>            Priority: Trivial
>
> set an expiry time on messages to be able to lower priority when message is considered not relevant any more.Reinier gave input to OCA: Optional queing of messages. Write CR proposal to address how to handle large amounts of queued messages.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)