All three are relatively light-weight processes. The IETF is the most tried-and-true for producing actual specifications of protocols and interfaces. The PEP process is also well-tested and battle-hardened, and the REP process effectively adopts the PEP process.
All three are based on the following basic concepts:
Anyone can propose something
Working code wins
Lightweight voting process for acceptance
In fact the processes spend more effort ensuring documents follow a good format, etc., than on prescribing a process.
The IETF process is the most well-defined, and includes detail on managing withdrawals, supersedings, conflicts, etc. It is probably too heavy-weight for us at this stage.
My recommendation is to adopt the PEP process with as few modifications as possible.
eSOL: What changes would be required if we use the PEP process?
No major changes, but the PEP process is designed for a language, so we may need to make changes to what is contained in a specification document to account for this.
Arm: Why not start from the REP process?
The PEP process is more up-to-date and better structured.
If we want structure, why not use the IETF process?
It is too heavy for us at this early stage. We prefer to start with a light process and add to it as necessary rather than risk a heavy process choking off contributions.
Linaro: Can we take existing source code from Autoware.AI to satisfy software tasks?
We can take algorithms, but the implementations need to be re-done to have tests, design documentation, user and developer manuals, be real-time safe (to the extent permitted by ROS 2), etc. Each algorithm needs to be implemented from scratch to meet these needs.
How are we going to deal with different vehicles?
We need to select a common vehicle platform. There is a task for this.
Not all companies have a vehicle.
Those without a vehicle will most likely be working in simulation, so they are good candidates to contribute to the simulation epic’s tasks.
AutonomousStuff already have a car that works with Autoware.AI. Do we need to redo their software?
Yes, it needs to be ROS 2-based, real-time, have tests and design documentation, etc. Hopefully AutonomousStuff will be willing to do this work. If not, someone else who is familiar with their hardware will need to do it.
The choosing the ECU task needs to coordinate closely with the reference platform WG.
Do these activities need to follow the specification process?
Yes
Does work that crosses over with other WGs need to follow those groups’ work or is it indepednent?
The other WGs are expected to work to these goals and follow the specification process. This is all one big project.
We are still in the early stages of this working group and haven’t settled on a regular meeting time yet; I hope we can do that in the next meeting. So to reach that point, we need to actually have that next meeting. Please fill in the following poll about your preferred time.