6.44 - External Interface (Wireless) Update
Tue, 2022-11-22 20:34 — RV-C Admin
Justification:
New DGN’s request and protocol for wireless devices communications for the RV-C.
- ALL DNGs listed in the attachment are TENTATIVE until this RV-C submission is approved.
| Attachment | Size |
|---|---|
| 6.44_External_Interface_Update_1122.docx | 6.73 MB |
Objections: 1) DSA listed in
Objections:
1) DSA listed in proposed Table 6.44 of 139 is for DC-Disconnect. Table 6.44 DSA parameter should be 143, see Table 7.2.
2) The proposed the External Interface / Broker structure appears to lack the capabilities of the remit of “B) Assess and report a robust protocol for interoperability among wireless devices within the vehicle, such as sensors, appliances and UI devices”. The keyword being “interoperability” in that do we want the foundation WRV-C messaging to provide the capability of a truly open recommended practice that will allow multiple suppliers to provide interoperable wireless devices. Currently it looks like the proposal is only proprietary since no connection payload or application data packet structures are referenced and no way to discriminate from proprietary. We may add a little more structure to the External Interface / Broker DGNs with parameters indicating if the connection protocol is Standard WRV-C or proprietary. The WRV-C connection open protocol will be developed next. This structure addition allows implementers to proceed with proprietary products without delay.
3) Connection Type in byte 2 of most of the proposed DGNs should be a reference to a new table of connection types to minimize documentation errors:
Table 6.44b- Connection types
Byte Connection Type
00 Invalid
01 Bluetooth
02
03
Request:
1) Request MODnet be added to the Connection Type parameter selection
Table 6.44b- Connection types
Byte Connection Type
00 Invalid
01 Bluetooth
02 MODnet
03
Discussions:
1) Recommend the Connection Text messages use Multi Packet messaging and only allow one Connection Text message be communicated at a time with each network Broker. Understood this will limit how fast multiple connections per Broker can be provisioned, but it is desirable the implementation of long text strings messaging be consistent with existing Multi Packet messaging. Are there any more reasons?
2) Is the Connection Text just a nickname or literal name for the connection, for use on RV-C? The Connection Text being a literal name works. It may or may not contain the advertised Bluetooth name. The advertised Bluetooth name may not be changeable and hard coded in the Bluetooth peripheral device and cannot be changed with the Broker Connection Text Command DGN. The Broker Connection Text Status can be consistent and the Broker Bluetooth central can mange the Connection Text by performing or NAKing the Broker Connection Text Command DGN if desired to keep the advertised Bluetooth name in the Connection Text.
3) Some existing wireless products use Network Bridge DSA 253 and DGNs are currently performing the proposed External interface / Broker function. Must they migrate with obsolescence or branch? Should Ethernet and other non-CAN LAN bridging be specified to use External Interface / Broker?
4) Should we be including information on connection data rates? Note big differences in Bluetooth Classic, BLE, BLE coded PHY, etc. data rates that may affect the application system operation.
5) Should we be including security actions like requesting new session keys and status? i.e.: BROKER_SECURITY_STATUS and BROKER_SECURITY_COMMAND DGNs
6) Should we be including information on Brokered W/LAN network IDs (i.e. SSID)?
Items 1 and 3 are acceptable
Items 1 and 3 are acceptable changes.
If I'm understanding the point of objection #2, it can be addressed by adding an entry to the Connection Type table, "Proprietary". If so, I propose using the value 253. This would be consistent with other examples where we support proprietary settings (e.g. battery charging). It keeps it at the end of the table.
It isn't clear what "MODnet" is referring to. A quick internet search suggests that "Modnet" has something to do with MODbus or Modbus/TCP, which is confusing. Can you elaborate?
Discussion Items:
1. It seems likely that transmitting multiple text items will be required in rapid succession - for example, to populate the fields for a diagnostic tool. The Multi Packet message doesn't handle that well. The extra identification fields in this method will make it significantly more reliable.
2. The Connection Text is deliberately "underdefined" here, as in the future it may be applied to a variety of protocols beyond Bluetooth. For Bluetooth, the natural assumption is that it is the advertised Bluetooth name, but nothing precludes the designer from using some other identifier such as MAC address or nickname.
3. The only absolute requirement of a device using DSA 253 is that it reports DMRVs using the relevant SPN table. There is no requirement to use these DGNs. However, as the WRV-C protocol moves forward, it is likely that these DGNs would be part of a "WRV-C Compatibility" requirement.
4. These are topics that the WRV-C group will address in the future.
5. These are topics that the WRV-C group will address in the future.
6. These are topics that the WRV-C group will address in the future.
.
In formatting the Connection
In formatting the Connection Type (objections #2 and #3):
Parameters should be as orthogonal as possible giving maximum flexibility for scalability and evolution.
Recommend we add a bit field for WRV-C or Proprietary. Preferred structure so we do not have to duplicate connection types that may have both capabilities of WRV-C and Proprietary into the connections table.
Recommend we add structure like:
Byte 2
bits 7-6
00 Proprietary
01 WRV-C
bits 5-0
Table 6.44b Connection Types
Table 6.44b Connection Types
00 Invalid or not specified
01 Bluetooth
02 Wi-Fi
03 MODnet
04 Thread
Additional information on the connection will be useful but difficult to tabularize, so we may include the information to the Connection Text strings for specific and SD functionality.
MODnet:
MODnet(R) is a dB Tech Inc developed and USPTO Registered Meta-Protocol framework that provides a high level of flexibility to handle the evolution of communication protocols with multiple PHYs and layers. With the recommended structure, MODnet can perform transparent WRV-C operability.
Discussion Items:
1. Understood, just recommending minimizing the implementation software overhead over potential slower serial data collection. We can live with it either way with a preference for existing Multi-packet. What does others think about this?
2. Good with Connection text being a literal string.
3. We expect to migrate to External interface with DSA 143 and SPNs for wireless connection borders in the future.
4.-6. We will continue to collaborate.
PROPOSED
PROPOSED ADDITION
-------------------
Add to the Broker Status section.
"For insecure connections, it is the responsibility of the Broker to serve as a firewall and prevent the connection from being used to access the Broker or the RV-C network in an insecure manner. Insecure connections shall be limited to communicating a well-defined set of data items, the spoofing or interception of which have minimal security consequences . It should not be possible to use an insecure connection to download firmware, transmit or receive arbitrary RV-C data, or otherwise bypass the physical security of the network."
I have a question as to what
I have a question as to what if there are multiple device types on the network that have Bluetooth.
How will the instances be controlled. Should not an address be part of the command data structure?
Destination address be the first byte in the payload then byte 2 would be instance?
A device might have more than one Bluetooth if it is a multi-instance device.
For instance, my controller controls lights, it can do that by CAN and/or by bluetooth.
I obtain an address for the lighting control but now do I have to obtain a second address to handle Bluetooth?
In my controller, all I want to do is be able to enable/disable Bluetooth and reset the passcode that the customer determines.
I was just going to use the Broker Connection Text Command and Status but there is no way for me to determine if the command is for me. When I report status the source address will let someone know it is form me but there is no way to tell if a command is for me.
It seems as if these command DGNs should be sent to a specific address and if the device has Bluetooth then it will accept these commands. This way I don’t have to get multiple device addresses.
How can I handle just changing the user passcode without having to get a second address for the controller?
Good questions. - The first
Good questions.
- The first instance is the instance of the Broker on the RV-C network. A network could have more than one broker. Just as with lighting, inverters, etc., the method of instance assignment is not called out specifically. It could be via the Instance Assignment DGNs, or with dip switches, etc..
- The second instance is the instance of the connection within the Broker. Again, we don't call out specifically how the broker manages them.
- Your product has one CAN Source Address. That's fundamental to RV-C - the SA is always specific to the physical CAN controller and nothing else.
- It will have one Lighting instance for each lighting circuit, exactly one Broker instance, and one Connection instance for each BT connection.
- Since your passcode is the same for all connections, you can simplify your configuration process just using connection instance 1 always. You could also just ignore the connection instance field altogether, but if you do that you should always echo the instance value in the last COMMAND when you send the STATUS.
In conclusion, here's all you have to do.
1. Just like you do with the lighting, come up with some means of determining the Broker instance. You can use the Instance Assignment DGNs, dip switches, or even just hard-coding them (although in the last case you run the risk that some other product hard-coded their instances to the same values.)
2. Your product then accepts the TEXT_COMMAND (Broker Instance as configured, Connection Instance 1).
3. Your product then responds with the TEXT_STATUS, same Broker and Connection instances.
Your product should also support the other command/status fields as appropriate.
Let me pass on one suggestion. Support the MFG_SPECIFIC_CLAIM_REQUEST DGN. Then any other device (like, say, a SilverLeaf touchscreen) can use that to get your source address, then send an address-specific request for the BROKER_STATUS and get your broker instance from that. I wish every company supported the MFG_SPECIFIC_CLAIM_REQUEST - it simplifies the discovery process and it's really easy to implement. (Make sure that your ADDRESS_CLAIMED message has some sort of product identifier in it.)