Fix tc secc ac vtb power delivery 010

[ikaratass]

fix AB#2853

[V2G2-225] The SECC shall send the negative ResponseCode
FAILED_ChargingProfileInvalid in the PowerDelivery response message if the EVCC sends a ChargingProfile which
is not adhering to the PMax values of all PMaxScheduleEntry elements according
to the chosen SAScheduleTuple element in the last ChargeParameterDiscoveryRes
message sent by the SECC.

[shalinnijel2]

It would be good to add two tests that covers the above mentioned use case as well - which is return a charging profile that doesn't fall on the same boundary as the chosen schedule - but is in line with the limits and one that is not.

[ikaratass]

done

[shalinnijel2]

This line could be removed as well.

[ikaratass]

Done

[tropxy]

we can add an else clause and break the loop. I know you said that it would stop also the outer loop, but cant be, I just tested:

In [1]: test_array = [1]*10

In [2]: test_array
Out[2]: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]

In [3]: test_array_2 = [2]*20

In [4]: for idx1 in test_array:
   ...:     count = 0
   ...:     for idx2 in test_array_2:
   ...:         count += 1
   ...:         print("the count is %s" % count)
   ...:         if count == 5:
   ...:             break
   ...:
the count is 1
the count is 2
the count is 3
the count is 4
the count is 5
the count is 1
the count is 2
the count is 3
the count is 4
the count is 5
the count is 1
the count is 2
the count is 3
the count is 4
the count is 5
the count is 1
the count is 2
the count is 3
the count is 4
the count is 5
...

as you see, with the code above, the inner loop stops at the count of 5, but the outer loop continues until the end

[tropxy]

So, I went over this and realized that that was not the problem. the code was breaking the loop, but it needed some more logic to work as expected. I added it and also included a more elaborated test and looks good ;)

[ikaratass]

Yeah, I tested as well, the problem wasn't this, we should check all profile entries to find the correct range to be checked. it passed all unit tests. Thanks.

[tropxy]

yeah, we had to check all the entries with the logic before, but the more EV profile entries more time it would take as in the worst case scenario, if we have N EV profile entries and M SA schedule entries, we would do NxM checks all the time. And the rationale is that the EV entries we have already checked during one iteration, do not need to be reevaluated for the next one.

[shalinnijel2]

I think we have missed one use case where the ev profile spans over two sa schedule entries.
In my test, the below given use case passed when it should have failed:
SA schedule:

[
PMaxScheduleEntry(p_max=PVPMax(value=11000, multiplier=0, unit=<UnitSymbol.WATT: 'W'>), time_interval=RelativeTimeInterval(start=0, duration=None)), 
PMaxScheduleEntry(p_max=PVPMax(value=7000, multiplier=0, unit=<UnitSymbol.WATT: 'W'>), time_interval=RelativeTimeInterval(start=1800, duration=1800))
]

EV Charging Profile:

[
ProfileEntryDetails(start=0, max_power=PVPMax(value=11000, multiplier=0, unit=<UnitSymbol.WATT: 'W'>), max_phases_in_use=3), 
ProfileEntryDetails(start=1200, max_power=PVPMax(value=11000, multiplier=0, unit=<UnitSymbol.WATT: 'W'>), max_phases_in_use=3), 
ProfileEntryDetails(start=1900, max_power=PVPMax(value=7000, multiplier=0, unit=<UnitSymbol.WATT: 'W'>), max_phases_in_use=3)
]

Notice the second entry with Pmax 11000W spans over the 1800secs mark from which point only 7000W is available.