This isn't directly 6.7 related, but I figured since there is talk here of system updates some may know what I am asking.

Are all the updates that Ford rolls out "clean"? As in they are not bugged some how to where the first round of the "update" could cause something else to change or act goofy?

The reason I ask is my service software for work does that. The program I have is updated, or supposed to be updated, monthly, and can run out to 4 months behind before it quits. I neglected to upgrade my program for November and December and it turned out that it was a good thing. We have something identical to an OBDII port where we can program CANBUS devices ("computers") and November and December software won't program them. My October version runs OK - we've done several systems that way now. Still waiting on our January update...

We also have ISO controllers that run some sub-CANBUSes and devices that communicate there that we update (not the primary CANBUS - that has to be run through the "OBDII"). This has been a headache as we run in to the exact above scenario - one operation/function/feature is added or improved and then other operations/functions/features act weird or lock the system up. I have a whole list of software versions that were "bugged".

Any similarities or, being the heart of the vehicle, the software payloads are pretty much bomb proof?

 

wait till gearloose gets here...he is a software guy with an opinion...

 

Should I wait for some amusement or get out of this forum while I can?

 

I'm a software guy too, and I can tell you that we don't make updates for the fun of it.. and there are SUPPOSED to be test cycle procedures to verify nothing else breaks.. but sometimes its obvious the test procedure is broken cause the thing you are fixing made it thru too.

I used to work for IBM, on the big mainframes, and when customers complained about defects, I would mentioned that every hardware instruction works, and we are fighting over some 4-10 uses out of order in 50million.. only we don't know which ones they are.

I spent 2 months debugging a problem with lost data on one of my pieces of code. lost data is a VERY bad thing..

right two instructions in the wrong sequence.. was A-B, instead of B-A, and that timing window (microseconds) allowed the problem to occur..

engine systems have a LOT more going on than my application did,

Sam

 

stick around...it will be fun

 

Not so long ago, I was in a discussion with different people about software standard DO-178B / DO-248B standards for mission and safety critical software.

http://en.wikipedia.org/wiki/DO-178B

The gist is every line in the code had to be individually verified --- and even then.. errors still creep in.

In the words of a senior program manager for a major aerospace firm --- they thought they did everything possible to create two "clean sheet" pieces... with 2 different development teams, that don't come from the same schools, worked in different locations, don't collaborate.. etc.

Problem: they set the spec document together --- and that document was flawed.

The errors cost a fortune to clean up.


Auto grade software is nowhere near DO 178B standard.

What do you expect?

Follow this link if you want some fun....

http://spectrum.ieee.org/green-tech/...runs-on-code/0

 

Great! Sounds like I'm not the only one that Although, I don't have a hand in software design. I do a lot of payloads though.

 

Want to have fun?





Software Reliability

 

Interesting. I never dove too far in to the code, but thats pretty wild.

I work in the agricultural equipment world - tractors, combines, sprayers, etc. In relation to the last part of the IEEE article with, instead of cars being driven, the cars drive the people - thats what I do right now with farm machines. I can set one up so the operator just has to hit the "idiot button" every so often to let it know that he/she is awake. The rest of it is driven by a computer. I don't mean driving straight down the field, taking control to turn around, and letting the computer pick back up - I can synchronize the hydraulics (for the implement), transmission (gear shifting, or if its an IVT the "speed"), and ultimately the steering based on distance and tweaked by time off of georeferencing. All the operator has to do is hit the button every so often, sit back, eat lunch, read the news paper... If you wanted to take it to an extreme you could hotwire it and jump out of the tractor and come back in 30 minutes with your field done... I wouldn't reccomend it, though

The problem with that application is getting someone to buy it - just like the article says, at what point are we willing to transition from driving the vehicle to letting it drive us? In an effort to maximize productivity the fact of automated machine control is like a robot on a manufacturing line - as long as you set it up right it does the job right and doesn't get tired. You just have to monitor it.

We can do the remote access for diagnostics and loading payloads NOW. The problem is it costs $$$ every time we do it because we have to go through a server and satellites. Then the customers say they don't want to pay us to remote into their machines when we can send a physical person out there that might be able to fix it on the spot.... If they are going to pay for a service call why would they want to pay more money to start the process? Its a hard concept to get over. In the end it is efficiency.

OK, so how did I get here from software payloads and bugs?

 

Think that is where the fat is.

Few farmhouses do not have wired phone service, and often with that DSL.

Many have wireless services as well

Why can't your stuff go through land lines vs satellite?

 

What happens when a guy is running a 530hp machine under max draft load and at 3:00pm in the evening, after it has been running around the clock since 7am, throws an over-heating code?

Whoever has that "account" gets an alarm on their computer at the store and we can take a look at it. Depending on the seriousness we can call and notify the operator so they don't blow $400,000 worth of a machine.

If the tractor is sitting in the barn plugged in, what good does remote access do?

 

I can see you need the satellite as a fail safe backup.

But I would set up a land line based primary system with a local, high power wireless (eg 1 to 3 watt) to talk to the equipment in the field.

That would cut the cost of dumping big files via the satellite, most of the time, it is not essential.

The satellite system you are using is primarily used for things like credit card transactions, tiny amounts of data... and pricey.

 

I can't remember what the name of the satellite system is. There is one that relays, essentially, WAAS corrections that we use but I don't know if it is the same one the remote access system runs through. We're all going to Florida for training next week so I'll find out. I do know for sending payloads to our new GPS receivers it takes a long time. Our normal payloads for those take anywhere from 10 to 45 minutes (depending on how many versions we skip, if it can even be done in one jump) but thats through the CANBUS off of the computer.

The problem with cellular technology is it doesn't reach everywhere. Does the SYNC system, OnStar, or any other similar system run off cell service? Phones do, unfortunately. It isn't an issue if you have good coverage but not everywhere gets good coverage.

We have a technology that allows sub-inch accuracy on guidance (similar to the surveying systems) that requires "base stations". There is talk of integrating all of this - the GPS correction signal as well as the two-way system management - but you creep in to the complexity of the cellular systems already in place. As it is, the options for running the GPS corrections through the cellular services require astronomically expensive high-data usage plans. Just like everything else with technology - costs will come down, but it will take some time. All the while technology will continue to evolve.

 

Let me give you a good one for software code going rogue.

Just purchased a new Terex front dump concrete mixer. Truck ran perfectly for the first week. They send down a gentleman to do a software reload on the system to fix a exhaust regeneration problem (big trucks have it too) Next day the driver loads up, backs out, switches to agitate mode on his bowl and pulls off the lot. By the time he gets to the stoplight, concrete is spilling all over the road. He looks back and the bowl is turning the wrong way??? He tries to override it but it won't stop. So he shuts it down. Turns out the reprogram combined with our truck config. made the computer mess up. Go Figure

 

And then you need to ask, who is writing all of this code for Ford? Probably the guys who couldn't get a job with Google...

In the electronics industry I work in, sometimes installing a software upgrade is just the wrong thing to do because of limitations in the original design of the hardware. Yet, people insist on backwards comptability so they can "stay current". Throw in the code errors and you have a recipe for disaster.