Slashdot Mirror

In the olden days we called this a 'ledger'. Bitcoin itself, I bought some at $500 for fun, it could crash, it could go to the moon. I've cashed out break even.

Now the blockchain is where I'm excited for my line of work (embedded automotive/industrial/aerospace). Accountable, recorded, distributed tracking of who signed off on what calibration and when.

The current crop of tools AVL CRETA and Vector vCDM are traceability abominations. Digging into the underlying system it's just a terrible wrapper on a SQL database. A DB admin could go in and flip the "Violate Diesel Emissions" bit without having to go through the front end.

When Grandma's self driving car goes through the Farmers Market the NTSB is going to start tracking down exactly when and who made the brake force calibration. I absolutely hope there's a block chain that points out it wasn't my decision to change it but Bob in accounting.

Oh, you hate your job? Why didn't you say so? There's a support group for that. It's called everybody, and they meet at the bar.

Also what is a 'developer'? I have a Mechanical Engineering degree and don't Identify with 90% of the stuff that comes up when Slashdot or most places discuss 'developers'. I write code for stuff like Simulink Embedded Coder, Vector CANape, dSpace boxes, etc.

Am I a developer? An engineer?

And this is just for desktop development. I can't imagine what most people here would say about automotive/aerospace, embedded toolchains. Nothing opensource comes close. The money is still cheaper than engineering time.

Simulink Embedded Coder, VXWorks, Green Hill INTEGRITY RTOS, ByteCraft eTPU compiler, Ashware eTPU compiler, Vector CANape, and on.

That doesn't even touch on the cost of development boards.

I always tell the new Engineers they don't really know CANape until they've read it in the original German.

Trying to create a Python CFFI driver is a nightmare the only thing I have to go on is the .h file they include with an install. And one document. The only hit for multiple different function names.

I have no idea who this sort of stuff is marketed towards but it's definitely not anything I've done in the last decade or so of industry.

but where does one start with the list?

Start with Simulink. Model based design is everywhere. Simulink is the only gorilla in the room at this point. With what I've seen people do with Python it shouldn't be hard (technically) to make something similar. You're going to have to make sure it meets industry standards like ISO 26262.

Pick a RTOS. ChibiOS, FreeRTOS, etc

A decent CANape replacement for calibration.

Then you're going to need hardware. You just need an open source version of the Caterpillar A4. Something that takes 18-28V, is hardened against lightning strikes and random stray voltages. Can handle thousands of hours under the hood of a diesel engine. It needs to have a eTPU or FPGA made for timing diesel injection events accurately. The rusEFI project has started their own ECM and in the last year gotten the absolute basics but is nowhere close to what engineered OEM ECMs provide.

Any one of those on its own would be a grad school level project (and should be).

Who exactly made the choice of tools to use in the first place?

Lots of people, here's a brief SAE technical paper on it: Caterpillar Automatic Code Generation

Why not choose non-proprietary hardware in the first place? Too simple?

As much as Slashdot hates to acknowledge it money makes things work. We pay a company to develop a compiler instead of hoping some volunteers do it for us. We pay a company to have parts of a toolchain in place so we don't have to.

Too simple? Too hard. There's no piece of open source hardware that comes close to what tractor ECMs could do a decade ago. The OSS community seems to be more interested in dev boards than actual finished products. This ECM is what drives a lot of the world of tractors. There are a dozen or so variations that have different pins populated with different IO but at its heart it's a 40(?) MHz Freescale MPC56XX chip with an eTPU to do all the fast timing.

But it exists because we paid engineers a lot of money to develop it. We paid more engineers to test it and even more engineers to write software for it all while paying outside companies for their tools to cut prototyping time. Vector CANape for CAN based calibration, Mathworks Simulink for model based control, Wind River for their diab compiler.

I would love to tear the ECM out of my VW TDI and replace it with one of our own. I could write a new controller for my car in an hour or two with our toolchain. Without the tool chain it's a PITA and I haven't bothered.

We treat our tools as tools. I don't question how or who designed my hammer when I use it to hit nails. I just care that it doesn't break and works as it is designed. The 'toolbox' I'm sitting on right now is the sum result of decades of development ahead of where open source is.

IF anyone wants to help develop a completely OSS ECM and toolchain for ECM development I have a laundry list of what is needed to catch OSS up with where industry was in 2005, but I'm not holding my breath.

Depends on what software you're using. I speak horrible german but a lot of documentation for Vector Canape is better in the original German.

If that is all you want AutoZone/AdvanceAuto will usually reset the lights and read the codes for free. They'll try and sell you the part to fix it, but they don't force you to buy it.

I use VCDS on my VW because when I'm diagnosing a problem on my car, I don't want to simultaneously diagnosing my tools.

It takes time and money to reverse stuff. There have been a few open source projects, but all stalled or weren't kept up to date. I see there's a new VW project on SF.

And as far as development goes, don't ask what a CANapelicense and hard ware cost.

There's even hardware to do it. dSpace sells some very nice (and very expensive) hardware to do testing. You can setup scripts to test almost any scenario. It'll fake out all the basic sensors and then you can test to see what happens when you hit the brake at 10 mph, 20 mph, 30 mph. You can do burn in tests. Software is very very repeatable. You can often trace right through the Simulink model and find out what is going on.

In the latest versions of CANape you can even view your Simulink Model EXACTLY how you built them and add all of your signal channels to it. If there is a bug or people are experiencing problems, it takes all of an hour at most to figure out what is going on and what is causing it.

And given the short cycle time, you don't have time to rewrite everything. Every company that uses Simulink for models even has verified and validated library blocks. We have a "C to K" block (because one isn't built in). That automatically matches In & Out data types, etc. We have low pass filters that are designed to our companies standards....

And we have engine control models that have been ported from Assembly that have been used for 30 years that 'work'. We're not going to throw that all out the window every development cycle.

Previous comments on how Simulink is used to write code in companies that use it.
SAE Paper on how Caterpillar uses auto coding generation to write their stuff.

It's not 100M lines of handwritten code! Every time this comes up everyone (especially those that work with embedded systems) seem to think that there are a ton of code monkeys locked away coding in C or assembly.

I'd be willing to bet that almost all of it is auto generated. Toyota (and nearly everyone else) uses Matlab & Simulink extensively.
The MathWorks tools help Toyota design for the future (PDF)

Toyota Racing Development Makes Faster and More Efficient Engineering Decisions with MATLAB

A simple PID controler with saturation and limits could easily take up 50 "lines of code".

And it's not like Toyota is Mathworks' sole customer. Boeing, GM, Chrysler, Ford, etc ALL use Mathworks.

Just like nearly everyone that works with CAN uses Vector CANape. Everyone that develops ICE powertrains uses AVL

When you start to get to specialized software like what Matlab, CANape, AVL, etc all do, there aren't a ton of options (and no open source solutions). It's cheaper for all of these companies to buy X product and use it than try to write their own.

Get your EE or ME degree and do controls. There's a whole field called "Mechatronics" dedicated to stuff like this.

I don't do anything but 'programming' all day. Data reduction via Matlab. CANape is scripted with more or less C. I know C, C++, Java, Matlab, Perl, PHP, VBA, Assembly (enough to read it), etc. It's just a tool.

But in addition to knowing that I know PID controllers (and how to implement in C or Assembly). It's just becoming such that knowing a how to program isn't the least common denominator. In the '70s what 18 year old boy COULDN'T fix his own car? It didn't mean he should be come a mechanic.

I work for a Fortune 100 company. We have an electronics division that does nothing but 'program'. Most program in Simulink, but for low level stuff we still have people that do C. (Stuff that runs real time.) We have people that are working on autonomous vehicles, people that write internal applications for the company, etc. I don't know a single "programmer". Every single person is an "Engineer" with either their Computer, Electrical or Mechanical Engineering degree.