Ongoing RFP Work
Two Devices and Data Profiles RFPs
In the summary report in Washington 2006 and follow-on discussions we have agreed to issue two RFPs. Bruce Boyes is heading the effort on the hardware device view.
Robotics Devices and Data Profiles Working Group 2006 Dec 4-6 Wash DC
Two RFP vs Single RFP
An initial draft RFP was hammered out by the Working Group, mainly from the Programmer API perspective. During the WG report on Wednesday there was Robotics DTF discussion of whether to create one or two RFPs. There seem to be many advantages to two RFPs:
- The programmer API is more abstract and could involved SDO and RT components considerations. Programmers aren't required to know about the underlying hardware (but we intend to allow low-level access). So the API view could, and maybe should, not concern itself too much with concrete hardware issues.
- The hardware device view should be as simple and concrete as possible. The reason is to simplify the software and firmware required by hardware vendors. Higher abstractions can be provided by the Programmer API layers. We want vendors to embrace the specification, so we don't want to burden them with understanding and implementing abstractions.
If we release two RFPs, we want them to be available in parallel.
We are very grateful to Dr John Eidson and Dr Kang Lee for presenting on IEEE-1588 and IEEE-1451, respectively.
Some Decisions 2006 Dec 06
- We must present RFP for review in two OMG meetings, but the release could follow the second review at the same meeting location. This opens the chance to release the RFP(s) at Brussels. This might be too ambitious due to the amount of work involved.
The St Petersburg FL (2007 Sep) meeting is at the same time as RoboDev, which creates a conflict for some members.
- We will incorporate IEEE-1451 tagging (TEDS) into our RFP
- We will consider JAUS 3.2 specifications in our RFP
- We will consider how to include IEEE-1588 synchronization concepts, mostly based on Rev 2, in our RFP. Because the concept of time is so important to useful wireless sensor networks, this should be more than just an option.