[apalrd]

Since we're (mostly) engineers on CD, let's think of this as an engineering problem. There is a supplier-customer relationship where FIRST is the supplier (of the control system) and the teams are the customers (of the control system).

The customer must have requirements for the supplier. The basic requirements for an FRC control system by a team are:

-Must be easy to setup for a very inexperienced team. Even if the manuals are clear, complex systems are inherently easy to misconfigure even if the directions specify how to do it.

-Must have a boot time of no more than (x) seconds for the entire system. I would be willing to exempt the DS only because I know how slow Windows is. This time limit is to the advantage of teams who want to run quickly, and the field crew which can recover from errors more quickly.

-Must have a certain amount of minimum functionality that can be achieved with minimal computer skills by a team - I would include a requirement for a certain amount of default code, at least mapping JS axis/buttons to motors and solenoids, since I know how many teams previously relied on default code. For some reason, the current control system lacks this and I don't really like it.

-Must be protected from any interference - I believe this requirement previously existed but was not fully met. I will discuss this later.

-Must have certain safety checks implemented - Specifically loss of communication with driver station, crashing of team code, and network error. Currently the first two are not implemented well, the third is implemented with a packet CRC which is good.

Good requirements? I think this covers the basics.

Now how do we verify that we've set all of the requirements correctly? How do we set the exact parameters of the requirements (boot time, amount of sophistication of hacking attempts, default code, watchdog timers, etc.)? Area they created by the supplier arbitrarily, or does the supplier actually know what the proper values are from their experience in designing control systems? Does the supplier actually work with control systems like these, or are they guessing based on experience in another field (say, industrial controls vs automotive controls - Timing and power requirements are *very* different between these two).

There are a few key flaws in this system which are highlighted above. Who is making the requirements that define boot time, maximum time without communication before the robot disables itself, or the minimum sophistication of a hacker attempting to compromise the security system? Do the requirements even exist, or is it more of a best-attempt system for some of these variables?

Best-attempt parameters always ends up as a variable which can be compromised to meat any other goal, with no real loss to the supplier.

The next step in engineering is actually designing the system. So, let's skip that step and end up with what we have now.

Once the system is engineered, you have to verify that you have met all of your requirements. How do you test this? While nobody thought to test the case of 802.11 access requests stated in the document, and this is OK given the obscurity of the bug and it's existence in hardware from another supplier, I can guarantee that somebody thought about DOS attacks on 802.11 (if they didn't, they would have not come close to meeting the requirement set above). What is the solution to them? The AirTight device was clearly chosen to detect DOS attacks, without adequate testing to verify that it actually met the requirements.

I am not pointing blame to anyone or any company specific, as I know there are many people and companies involved in the design of the system, but it has issues on a whole that are nobody's fault.

This document clearly shows me why 802.11 is not used in critical applications in this way (open SSID broadcast especially). No offense to FIRST, but the choice for 802.11 is probably the largest design failure of the entire control system (including my rants on compile/download/boot times and stuff). This testing, specifically the individual who is anonymous, shows just how vulnerable the system is, and how little it is protected from any intention or unintentional interference from a device that everyone carries in their pocket.

As a final thought, if the issues are blamed on the teams in such large quantities, then something must be too complicated, ambiguous, or otherwise error-prone in the system (basically the system is too complicated if that many people can't get it setup correctly).

Someone earlier in the thread questioned the failure at GTR as possibly being a related event. There were more failures than just GTR (although it was the most publicized) that showed up in exactly the same way as what happened to Simbotics. Teams' radios were blamed by FTA's, and everybody lived unhappily because the radios did suck (they thought) and there was nothing they could do to change it. The FMS was "above blame" - Because the DS could not ping the teams radio but the other 5 DS's could ping the other 5 radios on the field, it must have been the fault of the team's radio. (on a related note, the FMS gathers very little logging data for itself, most of it is collected by the DS and forwarded to the FMS). The general idea is that, since the cause isn't definitely the field, it's probably the teams (especially since so many teams have so many issues with the radio power wiring) and then it becomes always the teams fault, and the FMS is never blamed for failure of communication.

Anyone want to suggest another air interface? I've been thinking about a few...