We need to see the software

[dmethvin]

I would like to see more companies show us the software, especially in the case where they're asking us to upgrade it. A one-line description in an update document doesn't cut it. We can't know the extent to which a company has tested software before they release, but if the source code is available we can examine it and test it ourselves.

We trust our lives to a lot of software these days. Much of that software is hidden from us, without good reasons for it to be that way. The recent incident with the Ninebot firmware upgrade shows that even a "minor" software change can endanger your life and health. With physical components we get an idea of how they behave and change over time, but software changes can instantly modify the behavior of a device, often not in a good way. If you want other examples of the disastrous consequences of hidden software, see the Toyota firmware lawsuit or the recent VW emissions scandal.

The main reasons for auto or EUC makers to not show the software is "it's proprietary" but they can open-source the software with restrictions, for example against its use with other hardware the way Apple does with OSX. Of course perhaps the Chinese manufacturers do not trust intellectual property laws. Maybe they would also be embarrassed by showing how lax their software development and testing process is, much as happened with Toyota.

[zentype]

I agree, and at the very least put in a more descriptive change log.. "Bug fixes" is about the shortest description possible! They need to do a lot better than that.

Especially more thorough testing. We've got at least 3 guys here that now have bricked Ninebots and one with a broken wrist. And before they think about lowering the maximum allowable speed to prevent this sort of thing in the future, they need to realize it was the release of improperly tested firmware that did it.... Not the speed.

 

[esaj]

It would be nice to take a glimpse at the software used in the wheels, but I doubt the manufacturers are willing to show their "trade secrets", of course their competition has already reverse-engineered it, afaik, with proper hardware, you CAN read out the software-image even from a read-locked chip, there are even companies providing this service: http://www.break-ic.com/. 

What comes to modern cars, I've understood that they no longer have mechanical connection between the brake-pedal and the mechanical brakes, everything's controlled electronically. Like the recent hack of the Jeep showed, an attacker can take control of/disable brakes, steering, throttle... while that is more unlikely to happen, and probably there is redundancy in the system, still you could lose your control and brakes due to software fault or electronical glitch/failure. Guess the hand-brake (emergency brake) is still just mechanical though? Too much technology in vehicles (especially cars, that weight > 1000kg and can go way over 100km/h) is not necessarily a good thing...

Modern car software is among the most complex in the world, and probably has a lot of (non-critical?) bugs.

EDIT: Holy hell, that Toyota hardware & firmware sounds awful:

Toyota claimed the 2005 Camry's main CPU had error detecting and correcting (EDAC) RAM. It didn't.

Stack overflow. Toyota claimed only 41% of the allocated stack space was being used. Barr's investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn't incorporate memory protection to guard against stack overflow.

 

Why the fuck do they even use recursion, in pretty much any case it can be replaced with a simple loop... The needed stack size could then be determined with simple static analysis.

A litany of other faults were found in the code, including buffer overflow, unsafe casting, and race conditions between tasks.

  Was the software made by summer-trainees? Why is it multithreaded (other than separate watchdog-thread, which probably would be safer done with hardware-interrupts anyway...)?

 

[Tilmann]

As with cars, our EUCs consist of more than just one "computer" - there are minimum 3 processors with their own software at work! In addition to the main control CPU that drives the motor, the IMU and the BMS have a "life" on their own.

• The IMU (Inertial Measurement Unit) is commonly referred to as the "Gyro Sensor". In reality, it's much more than that: it's a combination from gyro and accelerometer sensors, some add a magnetic field sensor. To arrive at usable data, all the sensor readings are computed for plausibility and error correction (called "Sensor Fusion"). One critical mistake in those algorithms and the wheel "thinks" its upside down, while its not. There is a separate microcontroller inside the IMU and I believe, the firmware on the mainboard can update the software inside the IMU or at least change critical parameters.
• The BMS (Battery Management System) has been discussed here a lot. And we all learned: false software in the BMS can faceplant us anytime. I don't believe, the BMS software can be updated from the outside.
• Manufacturers start adding Bluetooth and entertainment functions (like Bluetooth speakers or speech synthesis). That's yet another processor and more software. And I'm convinced, that's just the beginning... Keep in mind: it was the entertainment system that opened the door for the Jeep hack.

The manufacturers seem to be decades behind understanding the importance of the software they are messing with. How else can we explain, that 

• security is practically non-existent. Every kid with a smartphone and a brain cell to guess a "1234" BT pairing code can reconfigure vital parameters of my EUC. Arrrrgh.
• Ninebot goofs 2 firmware updates with critical bugs in 6 months. Double arrrgh.
• there is no documentation, no standards, no interface descriptions - nothing. This is in part our own fault: when we compare features of different EUC makes and models, until now we didn't even include the ability for field updates to the firmware (which I believe to be essential, but as we learned a mixed blessing when done without the necessary care and expertise). We need to become more demanding in that respect.

Jepp, it will be an uphill battle to convince manufacturers to open their (presumed lousy) software. But: it is also a great chance for a smaller shop to find their niche in the market and set standards all the others need to compete with. If none of the manufacturers is willing to cooperate, I am very optimistic that the talent in the community will provide us with a generic set of software components sooner or later. I, for one, am very excited about the prospect of an EUC we truly know inside out.

[esaj]

As with cars, our EUCs consist of more than just one "computer" - there are minimum 3 processors with their own software at work! In addition to the main control CPU that drives the motor, the IMU and the BMS have a "life" on their own.

Very good points, but just to nitpick: I don't think all (or even most?) of the BMSs have CPUs, see this for example:

That's a 16S BMS with balancing & all the normal protections. I don't see a CPU anywhere. I think the protections aren't done with software, but passive current/voltage measurement circuits that control the mosfets to open/close? Somewhere (Endless sphere-forums maybe?) someone had modified the BMS under voltage / overcurrent protection limits just by changing some resistors, no software involved.

 

 

 

[Jason McNeil]

After seeing the recent issues Ninebot's firmware updates—and this is from a company that has loads of resources, probably more than everyone else combined— maybe there's something to be said with distributor but not-user upgradeability for critical safety issues only. It's always going to be a question of trade-offs, with these fault intolerant single-Wheels, the risks are probably too great with frequent undocumented updates. 

As a community, I think it's essential that we insist that a proper change-log is available so at least users are informed with what they're getting in an update package. 

I understand that most of the common code that's used in the bulk of manufacturers originates from ST Electronics. Ninebot have a large R&D department, so have probably completely rewritten their code from the ground up; IPS too have put in quite a bit of effort in creating their own software.   

http://www.st.com/web/catalog/sense_power/FM89/SC444/PF255590 

Convincing the manufacturers to use common opensource is, I think, not unrealistic; after-all, the with commoditization of components, one of the only things left in their arsenal for setting themselves apart from the competition is on the software front.

[Jebarus]

The electronic speed controller (ESC) that controls the power transistors to the motor has its own CPU. It is usually assembly code on a cheap microcontroller. It would be nice to be able to upload custom ESC firmware like BLheli to SimonK, which are written for quadcopters. It might actually increase the performance of the wheel.

[Tilmann]

Very good points, but just to nitpick: I don't think all (or even most?) of the BMSs have CPUs, ...

I stand corrected. Thanks Esa!

The electronic speed controller (ESC) that controls the power transistors to the motor has its own CPU. It is usually assembly code on a cheap microcontroller. It would be nice to be able to upload custom ESC firmware like BLheli to SimonK, which are written for quadcopters. It might actually increase the performance of the wheel.

Thanks for finding another CPU - being off by one when counting to 3 was slightly embarrassing . 

[esaj]

I stand corrected. Thanks Esa!

Actually, looking at more pictures of different BMSs, it seems that some of them do have some larger chips, which likely are some sort of microcontrollers/CPUs... so we were both wrong (or right, depending on your point of view)

[Tilmann]

While our exercises to count CPUs in our wheels may sound pretty pointless to most, let me try to construct a quick example, why this could matter to you. 

Ninebot leaves us guessing about what went wrong with the release 1.2.6, but was rather quick releasing 1.2.7.  That made some folks here speculate, that Ninebot simply took the latest safe release (believed to be 1.2.5), gave it a new version number - 1.2.7 - and pushed it out. A classic "rollback". If there was a library with all their releases somewhere, we could have done that ourselves. Its usually what I do when running into problems after an update.

Now picture this:

• Let's assume for a minute, that Ninebot wanted to improve the functionality of the ESC or the IMU or the BMS (if it got one with its own controller ). So they put a new version of the ESC controller software inside the new firmware as a payload.
• You update your ninedroid smartphone app. Inside, it carries the new firmware for your bot. Inside that, it contains the new software for the ESC in your bot.
• When your ninedroid app asks you to, you update your wheels firmware. Thats a separate update process! And when your new firmware is activated inside your bot, it then updates the controller software of the ESC. Which is yet another separate update process.
• Now you learn, that the update was troubled with dangerous bugs. You want to get rid of it. So, you start with a downgrade of the ninedroid app on your smartphone.
• You do realize, that downgrading the smartphone app does not automatically downgrade the firmware in your wheel - so you actively start the firmware transfer to the wheel and with any luck, you succeed (sometimes you can't, because the upload mechanism prevents you from using an older version).
• You think you downgraded back to the old version, known to be safe. You have no way of knowing: you didn't! That older version of the firmware you just "rolled back" to has no payload software for the ESC, so the update of that stays in. There is no rollback for the ESC software. Only heaven knows, if the ESC update caused the problems in the first place and even if it didn't, it may be deadly incompatible with the old firmware version. 
• In short: you're screwed and you have no way of knowing what happened.

Just in case you wondered, why we're so touchy about this subject of transparency...

[cg]

• In short: you're screwed and you have no way of knowing what happened.

Just in case you wondered, why we're so touchy about this subject of transparency...

And thats why we are back at @dmethvin original muse, that we must have open-source for our EUC.

[Kevin]

And thats why we are back at @dmethvin original muse, that we must have open-source for our EUC.

What would this accomplish from the manufacturer's point of view? Let me list out the 'benefits' if they released the source code:

1. Give away your 'secret sauce' for free.
2. 99.9% of users will never look at the code and just install the latest updates as usual.
3. 0.1% of users will scrutinize the code, get confused by some misleading comment or oddly structured code and immediately post all over the internet that you have a terrible bug that will kill everyone. Sadly, they will probably be wrong, and you will have been slandered for no good reason.
4. The same users will criticize your coding style, code architecture, programming patterns and denounce your engineering team as incompetent. This is bad press whether they are right or not, and even if they are right you don't have the option of rewriting your entire code base so..... ???
5. If/when something bad happens, even if *none* of the aforementioned users saw the problem and reported it - there will be a retrospective shit-storm of criticism where people with the benefit of hindsight will blame you for missing such an 'obvious' bug.
6. 0.000001% of users will be so grateful to you for showing the code and making it easier to find security exploits to shut down wheels and harm random passer by's.

So there you have it. All benefits, no downsides to releasing your source code. I think we need to formalize this list into a letter and mail it to Ninebot so that they can understand exactly why they should get on this TODAY.

[cg]

@Kevin  A agree ~16%

What would this accomplish from the manufacturer's point of view? Let me list out the 'benefits' if they released the source code:

1. Give away your 'secret sauce' for free.
2. 99.9% of users will never look at the code and just install the latest updates as usual.
3. 0.1% of users will scrutinize the code, get confused by some misleading comment or oddly structured code and immediately post all over the internet that you have a terrible bug that will kill everyone. Sadly, they will probably be wrong, and you will have been slandered for no good reason.
4. The same users will criticize your coding style, code architecture, programming patterns and denounce your engineering team as incompetent. This is bad press whether they are right or not, and even if they are right you don't have the option of rewriting your entire code base so..... ???
5. If/when something bad happens, even if *none* of the aforementioned users saw the problem and reported it - there will be a retrospective shit-storm of criticism where people with the benefit of hindsight will blame you for missing such an 'obvious' bug.
6. 0.000001% of users will be so grateful to you for showing the code and making it easier to find security exploits to shut down wheels and harm random passer by's.

So there you have it. All benefits, no downsides to releasing your source code. I think we need to formalize this list into a letter and mail it to Ninebot so that they can understand exactly why they should get on this TODAY.

1) it would not be secret.

2) agree, so what?

3) does not agree.

4) does not agree.

5) yawn...

6) does not agree.

 

The point you forgot; the 0.1% users, are more than your dev team, and will reveal one bug that would result in a face plant.

[Tilmann]

I would be rather surprised, if Ninebot would make the step to go open source. Despite all mishaps, I'm pretty sure, they consider their software a 'strategic advantage' over the competition and are not willing to give that up.

I would be more optimistic with smaller manufacturers, which are ahead in some hardware aspects (like Gotway with performance wheels), but dreadfully behind with software anyway. They face a tough decision: either build up their own sw-development department (and learn how to operate one) to avoid falling further behind, or focus on what they do best (hardware!) and let the community take care of the software. For free. Getting ahead of all proprietary softwares within weeks.

[Kevin]

@cg Sounds like you are simply more optimistic about people on the internet than I am. Perhaps I am just jaded from having read too many reddit and youtube comment threads.

[Tilmann]

@cg Sounds like you are simply more optimistic about people on the internet than I am. Perhaps I am just jaded from having read too many reddit and youtube comment threads.

Hi @Kevin, you may be right with the initial shitstorm, ok. But just for the sake of the mental exercise, stay with me for the Gotway example for a minute. Today, their unique selling point - performance - is being challenged by quite a few competitors (KingSong, IPS, even Ninebot with the "P" model). Their app is lousy and only available for android. Their latest release (as of more than 3 months ago) only works with your phone settings set to English (and maybe Chinese) or it crashes at startup. That's hardly a selling point, right?

Some 6 weeks after going public with their sources, their feature list on the sales leaflet could look like this:

• App compatible with android, iOS and Windows phone.
• Supports any "Wearable" on the market (android Wear, apple watch, Pebble, Recon Jet, google Glass, ...).
• Tilt back configurable to your liking.
• Audio alarms configurable to your liking.
• Field updates to your firmware through qualified shops.
• User selectable skins for the smartphone app.
• Localization for 100+ countries.
• State-of-the-art crypto and authentification for your security against manipulation.
• Secure locking function.
• Combined recording of track and wheel data.
• Data analysis to improve your riding.
• Configurable voice messages to your headphone...

Ok, maybe 8 weeks.

[LosCal]

While it would be nice, isn't that somewhat proprietary? They aren't running an open platform software. 

[Kevin]

@Tilmann I think this discussion was supposed to be about the firmware though, for which the barrier to entry for users to tinker with would be much higher. In addition, this carries a high risk of bricking your unit - so do you provide an 'official' way of loading custom firmware images and expose yourself to liability, or leave users to try and muddle it out themselves? What does the process look like for incorporating community contributions, and do you have bandwidth to do the necessary QA and possibly app changes to support them? Do you just incorporate community contributions into the 'official' firmware, or provide a 'marketplace' environment for users to choose their own preferred firmware (with associated risks)?

Don't get me wrong, as a user/modder I would love to be able to hack apart my wheel firmware and make it more customizable etc... but from the manufacturer's standpoint I think it would be a nightmare of complications.

[Tilmann]

@Tilmann I think this discussion was supposed to be about the firmware though, for which the barrier to entry for users to tinker with would be much higher. In addition, this carries a high risk of bricking your unit - so do you provide an 'official' way of loading custom firmware images and expose yourself to liability, or leave users to try and muddle it out themselves? What does the process look like for incorporating community contributions, and do you have bandwidth to do the necessary QA and possibly app changes to support them? Do you just incorporate community contributions into the 'official' firmware, or provide a 'marketplace' environment for users to choose their own preferred firmware (with associated risks)?

Don't get me wrong, as a user/modder I would love to be able to hack apart my wheel firmware and make it more customizable etc... but from the manufacturer's standpoint I think it would be a nightmare of complications.

Yeah, sorry, I see the sw components inside the wheel ("firmware") and outside ("the app") as parts of one system. Many of the hypothetic features listed above require changes to both firmware and app (like flexible configuration of alarms). I have to agree with you: tinkering with the firmware carries much more risk, than playing on the app side. 

The legal side: When you ask Solowheel to unlock the speed limit on your wheel, they ask you to sign a liability waiver. I would hope, that could be an acceptable legal safeguard with customers opting to replace the manufacturers firmware with something different. 

The technical side: here I am very optimistic, that the community will outnumber any development department of any EUC manufacturer in very short time in headcount and level of expertise. Granted, it will take some time and some iterations to come to a mode of reliable cooperation across continents, languages, preferences and tempers. Most likely it will start with a single release by a developer with already a good reputation in the community.

Quality assurance: Whether we like it or not, all of us are involuntary "test pilots" for insufficiently tested firmware already. I much rather risk my skin testing a firmware release candidate from a developer I learned to trust from many statements, work examples and skillful explanations plus a code review from another equally skilled wheelie, than trusting a company with irresponsive customer service, secrecy about their software and a history of failing to fix the most obvious bugs in their app for months. Alpha and Beta testing must be voluntary and the tester's feedback must be as public as the software itself.

Distribution: That's a tough one as most manufacturers don't even have much of a distribution network even for their sales - let alone repairs or software updates. I am skeptical, that over-the-air updates for EUC firmware are a such good idea. For Germany, I could envision shops like 1RadWerkstatt to take that role as a service provider (still leaving the responsibility for their choice of non-manufacturer firmware with the customer). Any good ideas how distribution could be setup across the planet anyone?

Compatibility/Change Management: the first credible firmware releases will without doubt come with a much superior interface to the outside world compared to anything we have seen so far. And whoever has enough sw-dev experience to give us better firmware is likely to define a fairly future-proof interface as a ground work to keep a basic feature set stable across release changes on one side only (i.e. new firmware or new app). When you look at many open source projects, you find their change management superior to most industry projects (likely due to the absence of 'managers' like me ).

The legal side, again: Today, EUCs have just not found their way into the traffic regulation of most countries. Once they do, manufacturers usually have to guarantee adherence to certain regulatory requirements in order to allow their customers to register their vehicles into a certain defined category (with all the associated aspects, like drivers license requirements, insurance class, etc.). Such regulation is likely to include max. speed, braking effectiveness and alarm levels - the very features, we like to get under our control with open firmware. In order to benefit from firmware improvements AND stay legal when that time comes, we should be prepared to give control back to manufacturers, and allow them to put a sealed version that complies with the respective laws into our wheels. Whoever brakes the seal to use another firmware version finds himself in a similar situation as todays car users do with an unauthorized chip tuning. 
So, conditions to leap frog development by going open source will never be better than today .

[Kevin]

On the technical side, I think the main difficulty will be getting people the tools they need to tinker with firmware. A lot is probably available directly from ST Micro, but programming rigs etc. could be trickier? Haven't worked with ST devices so not sure. I definitely don't think doing firmware development via over the air updates is feasible since all it would take is one bad build to put you in a non-OTA-programmable state.

For distribution, it could be as simple as accepting community contributions into their official git repo and releasing a new version via the existing over-the-air mechanism. The drawback of course is that you wouldn't be able to choose from a variety of firmware branches, and that changes you want made for any purpose would have to be formally accepted into the official firmware.

In any case, I think the only manufacturer that is currently even remotely likely to open-source their firmware is King Song, as 'the people's wheel'. It would certainly be interesting to ask them their thoughts on it, or perhaps see if they would take someone on as a volunteer developer as a first step 

[esaj]

About the botched OTA-update, haven't been following computer components for a good while, but already back in the day, there were some motherboards with "dual" BIOS, so if a BIOS-flash went wrong, it could revert back to the older (original?) version to get working again. Probably similar approach for programmable chips could work for wheels also, although it of course pushes up the price a bit due to extra components and design.

[dmethvin]

There are really two things here. One is having the manufacturer provide the software for inspection, so we can look at what's happening and (potentially) suggest improvements. If a manufacturer also wanted to go further and provide a developer version allowing us to create and download our own firmware (at our risk) that would be great, but that's a separate thing. 

The problem of how to fail safe is a really tough one for an EUC, considering that its prime directive needs to be "keep me balanced". With cars the software can detect a problem  by comparing various parameters and go into safe mode, quite often leaving you with a reasonably driveable car. I have no idea how well that would work with an EUC.

[Tom]

There are really two things here. One is having the manufacturer provide the software for inspection, so we can look at what's happening and (potentially) suggest improvements. If a manufacturer also wanted to go further and provide a developer version allowing us to create and download our own firmware (at our risk) that would be great, but that's a separate thing. 

The problem of how to fail safe is a really tough one for an EUC, considering that its prime directive needs to be "keep me balanced". With cars the software can detect a problem  by comparing various parameters and go into safe mode, quite often leaving you with a reasonably driveable car. I have no idea how well that would work with an EUC.

Without significantly changing the hardware of an EUC I don't think it's even possible. Redundant balancing circuits and possibly even a backup battery would be needed for full safety, which shouldn't be too difficult when you consider a redundant emergency system would only need to operate for as long as it takes to slow the EUC down and just keep the user balanced in the event of a total failure of the main system/battery.

[cg]

There are really two things here. One is having the manufacturer provide the software for inspection, so we can look at what's happening and (potentially) suggest improvements. If a manufacturer also wanted to go further and provide a developer version allowing us to create and download our own firmware (at our risk) that would be great, but that's a separate thing. 

I think this could be a good way, of course a brave few would probably go ahead and find a way to update the firmware and update it.

 

 

The legal side, again: Today, EUCs have just not found their way into the traffic regulation of most countries. Once they do, manufacturers usually have to guarantee adherence to certain regulatory requirements in order to allow their customers to register their vehicles into a certain defined category (with all the associated aspects, like drivers license requirements, insurance class, etc.). Such regulation is likely to include max. speed, braking effectiveness and alarm levels - the very features, we like to get under our control with open firmware. In order to benefit from firmware improvements AND stay legal when that time comes, we should be prepared to give control back to manufacturers, and allow them to put a sealed version that complies with the respective laws into our wheels. Whoever brakes the seal to use another firmware version finds himself in a similar situation as todays car users do with an unauthorized chip tuning. 
So, conditions to leap frog development by going open source will never be better than today .

Think of it in this way.

If you wheel get approved by some control organ...The second a new closed source firmware is uploaded, any tests that have approved the wheel are in reality invalid.

If a new closed-source firmware is uploaded, it should be tested by applicable organs, selling wheel to the entire world, This would mean only publishing the updates region wise, while the local control organ certifies the wheel.

having on open source framework, lots of changes in the firmware would probably be possible to identify as 'non-balancing/non-shutdown' critical. given that the code is correctly structured, the flow of updates could thus be made much cheaper for many firmware updates.

[Kevin]

Think of it in this way.

If you wheel get approved by some control organ...The second a new closed source firmware is uploaded, any tests that have approved the wheel are in reality invalid.

If a new closed-source firmware is uploaded, it should be tested by applicable organs, selling wheel to the entire world, This would mean only publishing the updates region wise, while the local control organ certifies the wheel.

having on open source framework, lots of changes in the firmware would probably be possible to identify as 'non-balancing/non-shutdown' critical. given that the code is correctly structured, the flow of updates could thus be made much cheaper for many firmware updates.

My experience with government certification (FCC radio testing) is that after initial certification is granted, the regulatory body just takes your word that any changes you make are non-critical with regard to what was certified... Only if something goes wrong and you get investigated you will have to provide documentation proving due diligence. Maybe this is different in safety critical applications? Either way, *if* source code is required to be inspected, it would only be shown to the regulatory body or licensed testing agent, and *not* to the general public.

Maybe if there were some open-source firmware that was somehow pre-approved, but I highly doubt that. For example, I can't imagine open source software ever being approved to be used in hospital equipment...

So the only way I could see this saving companies cost, is if one company were to get their firmware certified and then licensed it out to other companies for a fee. However there are a lot of drawbacks to that approach too - for one, certification would almost certainly be tied to a specific hardware setup, possibly even being restricted to being used with a specific control board. So basically everyone licensing this firmware would be selling the same 'generic' EUC...