Different rule types used for policies

[jyeo17]

After investigation of the 11 use cases on #752, we have found that amongst the different companies (Ride Report, Populus, Vianova, Blue Systems), different rule types are used for the Operating Area/ No Riding and No Parking/ Required Parking policies.

	Rule	Populus	Ride Report	Vianova	Blue Systems
1	Operating Area	Count			Time
2	No Riding	Time	Count	Count	Time
3	No Parking	Time	Count	Count	Time
4	Required Parking			Count	Time

This poses the question to operators if

1. Is it problematic to have to implement different rule types when working with different companies?
2. Is there a rational to pick one rule type rather than the other?

[bhandzo]

Yes this is problematic from the operator side. The point of having a standard is that consumers can build a standard implementation that works everywhere. In this case operators need to build logic into their ingest that is specific to the endpoint they are ingesting from, and manage that logic alongside the rest of their integration, keeping it updated as aggregators make changes.

In general the more degrees of freedom allowed for "agencies" the more complex the operator implementations will become.

[marie-x]

The plan is for the MDS WG to write some consensus-driven guidance mapping use-cases to how that use case should canonically be implemented.

[jean-populus]

For point 2 Populus doesn't have strong feelings for having one type of rules versus another. It would not be difficult for us to adapt to whatever the group consensus turns out to be.

@quicklywilliam, @S-eb your thoughts on this?

[quicklywilliam]

I wonder if it would be best to add some sort of "prohibited" rule type, rather than implying something is prohibited via a count or time? This might be a lot more intuitive/explicit and evidently covers several major use cases.

[S-eb]

The plan is for the MDS WG to write some consensus-driven guidance mapping use-cases to how that use case should canonically be implemented.

Yes @marie-x this is why the issue is posted here, to support this consensus

[S-eb]

For point 2 Populus doesn't have strong feelings for having one type of rules versus another. It would not be difficult for us to adapt to whatever the group consensus turns out to be.

@quicklywilliam, @S-eb your thoughts on this?

@jean-populus similar state of mind. We are open to adapt if required. Now there’s difference between rules types so might be interesting to discuss which rule type fit best a given use case

[mrsimpson]

Great you bring this up, @jyeo17 !

Imho, (and as we implement in DB Curbside Management), I see different aspects which the regulation focuses on, resulting in the different rule types:

• Parking of an individual vehicle => Limit duration how long a vehicle is allowed to be parked => aspect time, with the extreme of "not allowed" (duration = 0)
• Movement of an individual vehicle => Limit how fast a vehicle is allowed to move => aspect speed, with the extreme of "no riding" (speed = 0)
• Offering of a particular fleet => Limit the availability of vehicles within an area => aspect count, with the extreme of "no offering allowed" (count = 0). Of course, usually availability of a vehicle is defined by "a vehicle is parked", but the difference to parking is that a potential violation addresses not a particular vehicle, but the whole fleet. When violating a count rule, this is only evaluated once per rule (aggregating all vehicles inside the geographies referred to in the rule) and thus creates only max. one compliance violation. Think about a count > 0, say max. 500 vehicles in an operating area. If it's 501, which would be the one to violate the rule? Even more weird: If you had min. 200 vehicles agreed between city and provider but only 199 are parked or rented, which is the one missing 😬 ?

Thus, for DB Curbside Management (which is not on your list (yet) ;) )

	Rule	DB Curbside
1	Operating Area	Count
2	No Riding	Speed
3	No Parking	Time
4a	Allowed Parking	Time
4b	Required min. parking vehicles of a provider in Region	Count

[jyeo17]

Thank you all for your comments and input.
From the previous working group, it seems like there is a general concensus that:

• 'Time' should be used when the rule applies to the vehicle itself
• 'Count' should be used when it concerns controlling the number of vehicles in an area
• 'Speed' should be used when the rule seeks to control the speed of the vehicle

So, by specifying the definitions of the use cases, we have the recommendations below:

	Rule	Definition of use case	Recommendation
1	Operating Area	Defines the vehicles' boundaries of operation (Riding area)	Time
2	No Riding	Vehicles should not be in the area regardless of status	Time
3	No Parking	Vehicles should not be parked in these areas (available, reserved, non-operational)	Time
4	Parking	Vehicles must be parked in these areas.	Time
5	Parking Time Limit	Vehicles have a limitation of time on parking in these areas.	Time
6	Speed Limits	Vehicles have a speed limit in these areas.	Speed
7	Distribution Policies	Rules to control the amount of vehicles in areas	Count
8	Provider Caps or Minimums	Rules to control the maximum or minimum number of vehicles deployed by a provider	Count

[mrsimpson]

While I unserstand that speed is a difficult thing since it's telemetry and not event based, I don't quite understand how something related to time (something you can measure looking at your watch) can relate to the process of riding.
Outside in the real world:tm: , "riding" is defined by "something is moving" and movement is something you measure by determining its speed.
@jyeo17 Can you shed some light which time (value and unit) would be used to define "no riding"? How is this different from "no parking" ?

[S-eb]

@mrsimpson Thanks a lot for your comment!

Here our understanding of “time’ is amount of time spent by a device in a given state.
A No Parking rule would result in allowing no more than 0 minutes in the ‘available’ status in a given geography.
A No riding zone would result in allowing no more than 0 minutes in the ‘on_trip’ status in a given geography.
Does this make sense?

[quicklywilliam]

The above table is really helpful and I think the interpretations given are very reasonable. That said, I agree with @mrsimpson that using time to cover a No Ride Zone is very unintuitive. And I think it's an orange flag that we are leaving so much up to our differing interpretations. I don't think you should have to read detailed documentation to understand such a basic, common Policy use case.

My suggestion is that we take this opportunity to make the Policy API more explicit and use-case driven, such as adding a prohibited rule type. The current implementation is derived from the original design goal of having everything be 100% interpretable via an abstracted state machine interpreter. That goal hasn't matched up with how Policy is used IRL, where implementations can differ greatly and interpretation is often done by humans.

[schnuerle]

We will be discussing this at tomorrow's working group meeting.

[mrsimpson]

@S-eb sorry for taking so long to respond – it took me a while to clear my throat fingers in order to respond kindly to your question without sounding rude (which we Germans are said to tend to do ;) )

Does this make sense?

After two days of picking my words carefully, I'd kindly reply "that depends how you look at it".

If you mean "Is this a change for the better and does it make policies easier to interpret" I'd say "hell no!" ;) Currently, the rule rules have feature a rule_type which classifies them. This classification relates to the aspect which shall be governed. I do think it's strange that the same rule type may refer to different vehicle states – and equally may make only sende in combination with a particular state (speed would only apply to the vehicle state on_trip).
If you mean "Can we utilize the unit time and the vehicle states to express how long a particular vehicle moves within a city" I'd agree: That makes some sense. Are there other ways to express the same: I do think that describing which aspect of a vehicle utilization shall be regulated is much better since the vehicle state would be generally independent from the rule type, but may be used to further specify particular rules.

I do think we really have to decide about the target audience of an mds policy document.

• If it's meant to be interpreted by machines implemented by different developers all over the world, I'd expect the written specification to include real world use cases and their mappings to the technical representation so that developers of user-facing interfaces can code it equally.
• If it's meant to be understandable for humans, I'd love to see a disruptive change which allows the use case (like "no riding") to be explicitly stated in the rule (maybe as an enum-value of rule type). Then, we'd ... well also need the written specification to include real world use cases and their mappings to the technical representation so that developers of compliance-checking services can code it equally.

I hope I could make sense with writing that – it's a bit tricky for me as a non-native writer to find the right words, but I tried my best.

@schnuerle I'll take your statement as an invitation and will try to attend tomorrow's meeting

[jean-populus]

I'd like to take a step back and see if we have consensus on the Use Case Definitions in #764 (comment) because this will inform our thinking on speed vs time and using prohibitive rules.

Are the Use Case Definitions how most municipalities and providers are interpreting these rules? In particular No Parking means Vehicles should not be in the area regardless of status.

[schnuerle]

We will be talking about this at this week's MDS meeting.

[mrsimpson]

We discussed in our development team what is really the problem that different applications map use cases differently into rules.
Our finding was that the engine that interprets the rules has no problem at all with the different mappings: A compliance processor can quite easily evaluate whether a vehicle has violated maximum speeds, stop times, or if a fleet has violated counts based on the transmitted telemetry.
Rather, the problem lies in the comprehensibility by a human. Therefore, we questioned whether it might not make more sense to leave the API as it is currently designed (optimized for machine-to-machine) and introduce a second interface that focuses on human authoring.
Ideally, a library could then also be provided as a referential implementation that realizes this mapping between use case and policy.

[jean-populus]

So it seems like we have consensus on everything except for the No Ride rule.

For the No Ride the description should be broadened to be -

Vehicles should not be in the area.

Which covers the two use cases discussed during the call

1. Vehicles cannot be ridden in the area but may be dragged into and parked there.
2. Vehicles cannot be ridden in the area nor parked there (no PROW vehicles).

If we want to have just a single rule_type, that means for the options -

• speed cannot be applied to both use cases
• time was considered not intuitive

So that leave count as the best option for a No Ride rule. Any thoughts on the recommendation to use count as the rule_type for a No Ride area?

[marie-x]

Lacuna is (for now) using count, although we used to use speed. We had to change our compliance measurement mechanisms to include telemetry, but that seems to be working well. It also means that we can't adjudicate violations in real-time in LA, because telemetry is delayed by up to 24h for privacy reasons.

[mrsimpson]

I still can't understand how one can count the process of riding: Riding something is a process (movement over time), it can be measured as speed. What would be counted? What would a "count" rule for a no riding look like? And how would it be differentiated from a no-operating-area for a particular provider (which is obviously a very different thing to regulate)? Can you please elaborate on that?

In the call, a representative of an operator (William?) also brought up the fact that preventing a ride is technically sanctioned on the vehicle => Speed rules would be deployed to the vehicle so it can safely reduce the speed (at most to 0) when entering a no ride area. To me, this is a very strong pro for implementing "no ride" as speed.

That leaves the issue that speed does not address that the vehicle should also not be parked (bullet point 2. on @jean-populus 's list). I strongly recommend that this is expressed as a second rule (of rule type time, max 0s): This rule would then be naturally be deployed to the operator's app making it impossible to terminate the rent within this rule.

Any objections on this approach?

[jean-populus]

You can count vehicles that are on_trip to count the process of riding. This works in most cases as trip telemetry and speed isn't usually measured in real-time.

Parking in a No Ride zone isn't how the majority of cities are implementing this policy so I recommend we use count for No Ride policies as the primary implementation and include an alternative option for speed when parking isn't part of the policy.

[jyeo17]

After all these discussions, it seems like the agreement that we have come to is:

	Rule	Definition of use case	Recommendation
1	Operating Area	The vehicle should stay within the areas of operation defined (Riding area).	Time
2	No Riding	The vehicle should not be in one of these defined areas regardless of status.	Count
3	No Parking	The vehicle should not be parked in one of these defined areas in the statuses Available, Reserved and Non-operational.	Time
4	Parking	The vehicle should be parked in one of these defined areas.	Time
5	Parking Time Limit	The vehicle should only be parked in one of these defined areas for a limited amount of time.	Time
6	Speed Limits	The vehicle should operate at a specific maximum speed in these defined areas.	Speed
7	Distribution Policies	The amount of vehicles spread amongst these defined areas are controlled.	Count
8	Provider Caps or Minimums	The maximum or minimum amount of vehicles deployed by a provider are controlled.	Count

[schnuerle]

Resolved with #786