" But the latter is because of the former, isn't it? It's easy because you can operate at the abstraction level of the problem instead of having to deal with low-level implementation details."
I agree.
" Does it really matter all that much that people do already know it? It's not exactly my area of epertise, but in my world, the underlying concepts are far more important than the specific language you are using. If you do know what classes, closures, pointers, references, higher order functions,... are and how to apply them to solve problems, you just pick up a new language that has those features if needed."
Most of the people who they had using Simulink very successfully, would never be able to code in any low level language. Pointers would kill them.
" But revision control by changing file names? At least in the general software world, that's close to a reason for being fired:-)"
The controls group managed releasing code, and they used a VCS (Subversion I believe) When doing development, they would get the latest version of production code: Example: 2014_prod_V8_SCI_014.XXX and make it: 2014_dev_V8_SCI_014_Project#_New_Knock_StrategyX_Your Name_Today.XXX That would be sent to the engine guys and used for development, and when they were happy with it, they sent it back to the controls group who checked back into VCS and possibly merged it into the production code.
We would make 3 or 4 versions on the dyno, and take them to the water to test. The test data would reflect the name, and all the versions would be kept in the VCS to recreate the test. Meetings were held to review the data, and a choice was made as to which version would get merged into the production code and when.
Many times 5 or 6 different sub-projects would contribute changes to a final new model engine, so one group would add cooling system updates, another base engine control updates, another knock system updates, and all of these little changes get merged back into the production code by the controls group and that then gets tested on endurance and verified against the data from the original tests.
With anybody and everybody making code, you had to have a way to identify what was what, and having some of the info in the filename made sense. The projects were all tracked in Oracle, and Teamcenter, so finding the details of a test by the project number was easy. Having 100 different versions of code floating around with the same filename would be crazy.
There was a final build script for production code that built every version for every engine (50 or so V4, V6, I6, V8, 2 stroke, 4 stroke, Supercharged, turbocharged, catalyst, Direct Injected,) at once, and then those were distributed to the various teams for use in production. That way bug fixes, and updates made it to every version they made.
Have you looked at: www.mathworks.com/products/hdl-coder/
From the above link:
HDL Coder generates portable, synthesizable Verilog and VHDL code from MATLAB functions, Simulink models, and Stateflow charts. The generated HDL code can be used for FPGA programming or ASIC prototyping and design.
HDL Coder provides a workflow advisor that automates the programming of Xilinx and Altera FPGAs. You can control HDL architecture and implementation, highlight critical paths, and generate hardware resource utilization estimates. HDL Coder provides traceability between your Simulink model and the generated Verilog and VHDL code, enabling code verification for high-integrity applications adhering to DO-254 and other standards.
The abstractions, and how easy it is to add / change things. It is so much easier to add and change things in Simulink than in C. Want to add a filter, just drop it in your diagram, want to change the type of filter, it's only a few clicks away, instead of having to manually add / delete all the required variables, be sure you use them in the math correctly, and then add all the things you want to manipulate to the database that the calibration tool interfaces with. We used to wait weeks for changes that took hours to make with Simulink.
It's not a Simulink specific thing I guess, it's just one of the few tools that could do that type of modelling. If there were other programs like that, (that everyone knew) you could use those as well. Matlab / Simulink also has a C code generator, and we used that, so that definitely was one of the main reasons.
Revision control for production code was done by the controls group. Everyone in development was encouraged to use a specific format of base model year SW version, project, engine, variation, user, and such to name everything so you could keep track of what was what. The ease of changing things meant you could keep using the same filename for a test until you found what worked the best, you didn't end up with a version (filter a, filter b, foo filter) for every change you made, so we ended up with less versions as a result.
To merge finished changes, you just add the new blocks to the model, and as long as the variable names are the same (they better be WTF is MyRPM) it links up with very little effort.
The diff tools in Simulink generate a comparison report, and you use that to merge changes.
The familiarity, and the fact that it was already being used to do the modeling.
It's much easier to find people who are well versed inMatlab / Simulink VS. coding in C, especially the PHDs who really understand dynamic process control and simulation.
We already used Simulink to do the control algorithm design and simulation, but then we had to write detailed software specs to be hand coded by the controls group (to hope we got the same results) Sending them an updated Simulink model to be linked into the production application (and being able to rapidly make changes to the production code for testing) was a much more effective use of everyone's time.
There were still only a few people who really knew how it worked, but anyone who knew Simulink could get it to do whatever they wanted without having to deal with understanding the interactions in many thousands of lines of C code.
Wrapping a PID around a PID that's already around a PID is much less error prone in Simulink, and much easier to integrate into the application
You can have thousands of lines of code generated by a 5 minute update to a Simulink diagram. Copy it, paste it, delete it, change it around 5 ways on Wednesday, all without having to worry about breaking it, or leaving something behind that will haunt you.
Testing was also much easier as the functions knew the range of their variables and the whole thing could be simulated in Simulink to verify itself.
The last place I worked went from hand written C code to using Simulink to generate the (C) code for use in their ECMs.
The entire engine: airflow model, fuel injection, and emissions system was just a bunch of pretty pictures in Simulink. You can drill down by clicking on the high level diagrams to see the nitty gritty of each process if you so desire.
It was not nearly as efficient as the hand coded version, but there were far less issues with bugs, and it allowed us to have (many more) math / simulation types coding instead of just a few C gods. There were libraries that Simulink hooked in to that let it configure the hardware, but those were hidden away from the day to day people diagramming code.
The one time I slugged it out with Wolfram Alpha, I learned a lot about the question at hand just trying to figure out how to get it to calculate the right thing, and then it gave me the wrong answer!
The key is something used constantly, can't it be kept in on die L1 or L2 cache? If it ever had to pass through RAM on the way from the HDD, just overwrite the area in RAM a few times, and leave it on the die for the whole time the computer is running.
I''d venture to guess that keeping the key in the on CPU cache makes it an order of magnitude harder to get than keeping it in RAM.
We use industrial VPN router / gateways that allow us to have our own certs and encryption keys. They have a digital input connected to the PLC that the customer turns on with a password protected maintenance screen on the HMI and / or a lockable key switch. The customer will call us, and we then calculate and give them the password to enable the VPN, they unlock it, and then we are able to remotely connect to the machine and service it.
Unless we have walked the customer through enabling remote access, the router is not connected to any network, and it will not respond to a ping or port scan. It has all the security of the network cable being unplugged, but we can activate it without having to lockout the machine and open the control cabinet.
These routers are very popular, and can also log access information, performance data, and error messages. There are even versions that can verify the PLC program, configuration, and databases to be sure it has not been (Stuxnetted) modified. If the firmware detects anything has been changed it will automatically reload the system from a self-signed backup contained in the router, send us an EMail with what was changed, and attach various logs.
I have had factory training on these routers, and after seeing the features and interfaces, I've asked what operating system they run. Of course it's Linux, but the manufacturers do not release their source code! They would make an awesome little hackable home router / VPN / Fileserver, but they are locked down, and most have cryptographically signed firmware and bootloaders (ala Tivo) that refuse to run any modified code. Some of them will even erase themselves if they detect anything out of the ordinary going on.
I've tried to plead my case that as a buyer of that hardware I am entitled to the source code, and even mentioned that they should sell an unlocked and unsupported version to allow customers to integrate them into different applications. I always get the same answer. "These devices use OUR OWN PROPRIETARY LINUX, and we do not provide it to anyone for security reasons"
So now I am on the search (anyone???) for a BSD based (anyone???), or properly supported Linux version (anyone???) so I do not have to support the GPL violators. I'm tempted to notify RMS, I want to hack on one of these in the worst way:)
The routers have multiple VLANs that can be configured on a port by port basis because most of these systems are connected to (at least) the intranet nowadays, and it is nearly impossible for them not to be. The setpoint recipes, quality control, inventory, ordering, historical data, productivity, and monitoring of these machines is always done remotely, even if it is in the same plant.
You just configure the router to give the the device its own VPN / VLAN to the exact device it needs to connect to. Hardly anyone walks down on the factory floor to copy data with a memory stick anymore, it's too risky for the poor unpatched naked Windows installations being used. Some of them are configured to automatically connect once per hour / shift and dump their data to a central database and then disconnect, but most of them are always connected to various supervisory control systems. Most of the HMIs and data access servers are MS Windows NT / 2K / XP based, and rely heavily on MSSQL, OLE, and crappy vendor supplied closed source drivers to interface Windows to the various Industrial Networks.
Usually these old unpatched Windows machines just connect to the various databases with a specific VLAN for each one, and then the properly patched and AV'd supervisory systems (now mostly Windows 7) make their own connections to the databases and push or pull the necessary data from them without ever connecting directly to the vulnerable unpatched PCs that are actually controlling the process.
Yet... For some reason I'll bet the app from my cable company has much better security protecting their content than all of these bank apps put together.
Just imagine if the shit hits the fan, and there are large areas without power, and / or internet access. Your Bitcoin will be worth exactly zero, as you'll have no way to cash them in.
When you flip the switch the reflecting surface changes from the polished back surface of the mirror to the front surface of the glass which is no where near as shiny.
One day I remember going in to my Radio Shack to get a counter IC and found the whole area gone, and the manager (Steve) told me that they were clearing everything out, and not replacing it. It was all in a big octagonal cardboard clearance bin. I offered him $20 for the whole bin, and took the bin and everything home. I still have it, It's not used as much any more, but when you are thinking dang, where am I gonna find one of those nowadays, it is sure handy.
Unless you made the logic gates yourself, how can you be certain your binary adder is not just an arm chip emulating a logic gate, that turns your binary counter into a satellite link and secretly shift your bits to the NSA when it detects it's not hooked up to a logic analyzer?
I bought an 80GB Intel X25-M about 5 years ago, and I have done nothing to give it any breaks for being an SSD. All logging, swap, cache, etc is still at default or higher levels, and I've filled it hundreds of times. It has 6 partitions on it, and I move data around between them constantly.
I have a 16GB extended partition for installing the distro of the week that has seen over 200 installs just to try them out, or test RC's for bugs, or test changes to my main install, and I copy whatever I downloaded there to another 40GB partition that I use for my shared directory. That partition has downloaded over 5TB of stuff that has been either transferred to an external drive, and/or burned to DVD. I have transcoded and remastered over 2TB of DVDs removing the junk that comes on them from Disney etc and converted them for my portable devices. I have also ripped in my 500 CD collection 3 different times at ever increasing bitrates. I take thousands of pictures in burst mode to get the right moment, and then load them all and sort through them and delete 75% of them. I shoot and edit / transcode HD videos by the GB, and I have never once given a thought about wearing out the drive (backups!) and I use it like I would any other spinning rust drive.
I finally got to 99% on the life left wear indicator as reported by SMART and I've yet to have any sectors fail and have to be remapped to the spare flash. If I can do that for the next 100 years, and still have 75% life left on the flash, I'd say it's good enough for me!
Slashdot Mirror
sorry replying from my phone...
" But the latter is because of the former, isn't it? It's easy because you can operate at the abstraction level of the problem instead of having to deal with low-level implementation details."
I agree.
" Does it really matter all that much that people do already know it? It's not exactly my area of epertise, but in my world, the underlying concepts are far more important than the specific language you are using. If you do know what classes, closures, pointers, references, higher order functions, ... are and how to apply them to solve problems, you just pick up a new language that has those features if needed."
Most of the people who they had using Simulink very successfully, would never be able to code in any low level language. Pointers would kill them.
" But revision control by changing file names? At least in the general software world, that's close to a reason for being fired :-)"
The controls group managed releasing code, and they used a VCS (Subversion I believe) When doing development, they would get the latest version of production code:
Example:
2014_prod_V8_SCI_014.XXX
and make it:
2014_dev_V8_SCI_014_Project#_New_Knock_StrategyX_Your Name_Today.XXX
That would be sent to the engine guys and used for development, and when they were happy with it, they sent it back to the controls group who checked back into VCS and possibly merged it into the production code.
We would make 3 or 4 versions on the dyno, and take them to the water to test. The test data would reflect the name, and all the versions would be kept in the VCS to recreate the test.
Meetings were held to review the data, and a choice was made as to which version would get merged into the production code and when.
Many times 5 or 6 different sub-projects would contribute changes to a final new model engine, so one group would add cooling system updates, another base engine control updates, another knock system updates, and all of these little changes get merged back into the production code by the controls group and that then gets tested on endurance and verified against the data from the original tests.
With anybody and everybody making code, you had to have a way to identify what was what, and having some of the info in the filename made sense. The projects were all tracked in Oracle, and Teamcenter, so finding the details of a test by the project number was easy. Having 100 different versions of code floating around with the same filename would be crazy.
There was a final build script for production code that built every version for every engine (50 or so V4, V6, I6, V8, 2 stroke, 4 stroke, Supercharged, turbocharged, catalyst, Direct Injected,) at once, and then those were distributed to the various teams for use in production. That way bug fixes, and updates made it to every version they made.
Cheers
Have you looked at:
www.mathworks.com/products/hdl-coder/
From the above link:
HDL Coder generates portable, synthesizable Verilog and VHDL code from MATLAB functions, Simulink models, and Stateflow charts. The generated HDL code can be used for FPGA programming or ASIC prototyping and design.
HDL Coder provides a workflow advisor that automates the programming of Xilinx and Altera FPGAs. You can control HDL architecture and implementation, highlight critical paths, and generate hardware resource utilization estimates. HDL Coder provides traceability between your Simulink model and the generated Verilog and VHDL code, enabling code verification for high-integrity applications adhering to DO-254 and other standards.
Just curious if it works or not.
The abstractions, and how easy it is to add / change things. It is so much easier to add and change things in Simulink than in C. Want to add a filter, just drop it in your diagram, want to change the type of filter, it's only a few clicks away, instead of having to manually add / delete all the required variables, be sure you use them in the math correctly, and then add all the things you want to manipulate to the database that the calibration tool interfaces with. We used to wait weeks for changes that took hours to make with Simulink.
It's not a Simulink specific thing I guess, it's just one of the few tools that could do that type of modelling. If there were other programs like that, (that everyone knew) you could use those as well. Matlab / Simulink also has a C code generator, and we used that, so that definitely was one of the main reasons.
Revision control for production code was done by the controls group. Everyone in development was encouraged to use a specific format of base model year SW version, project, engine, variation, user, and such to name everything so you could keep track of what was what. The ease of changing things meant you could keep using the same filename for a test until you found what worked the best, you didn't end up with a version (filter a, filter b, foo filter) for every change you made, so we ended up with less versions as a result.
To merge finished changes, you just add the new blocks to the model, and as long as the variable names are the same (they better be WTF is MyRPM) it links up with very little effort.
The diff tools in Simulink generate a comparison report, and you use that to merge changes.
www.mathworks.com/help/rptgenext/examples/merge-simulink-models-from-the-comparison-report.html
Cheers.
The familiarity, and the fact that it was already being used to do the modeling.
It's much easier to find people who are well versed inMatlab / Simulink VS. coding in C, especially the PHDs who really understand dynamic process control and simulation.
We already used Simulink to do the control algorithm design and simulation, but then we had to write detailed software specs to be hand coded by the controls group (to hope we got the same results) Sending them an updated Simulink model to be linked into the production application (and being able to rapidly make changes to the production code for testing) was a much more effective use of everyone's time.
There were still only a few people who really knew how it worked, but anyone who knew Simulink could get it to do whatever they wanted without having to deal with understanding the interactions in many thousands of lines of C code.
Wrapping a PID around a PID that's already around a PID is much less error prone in Simulink, and much easier to integrate into the application
You can have thousands of lines of code generated by a 5 minute update to a Simulink diagram. Copy it, paste it, delete it, change it around 5 ways on Wednesday, all without having to worry about breaking it, or leaving something behind that will haunt you.
Testing was also much easier as the functions knew the range of their variables and the whole thing could be simulated in Simulink to verify itself.
Mostly black, or blue (now available with custom colors)
We put them in some big yellow things for testing though.
www.mercuryracing.com/sterndrives/hp1650.php
The above is all Simulink powered including the drive by wire.
The last place I worked went from hand written C code to using Simulink to generate the (C) code for use in their ECMs.
The entire engine: airflow model, fuel injection, and emissions system was just a bunch of pretty pictures in Simulink. You can drill down by clicking on the high level diagrams to see the nitty gritty of each process if you so desire.
It was not nearly as efficient as the hand coded version, but there were far less issues with bugs, and it allowed us to have (many more) math / simulation types coding instead of just a few C gods. There were libraries that Simulink hooked in to that let it configure the hardware, but those were hidden away from the day to day people diagramming code.
Cheers!
Sure there are...
I've seen THOUSANDS of 3 digit UIDs around here lately...
The one time I slugged it out with Wolfram Alpha, I learned a lot about the question at hand just trying to figure out how to get it to calculate the right thing, and then it gave me the wrong answer!
It needs a Watson front end.
And with a userbase of 2^22 /. likely has less than 2^16 that contribute useful (nerdy) comments.
I'll see your pudding dipped twinkies, and raise you Mandarin oranges in chocolate pudding FTW!
What if you used that Visa gift card to buy Bitcoin?
The key is something used constantly, can't it be kept in on die L1 or L2 cache? If it ever had to pass through RAM on the way from the HDD, just overwrite the area in RAM a few times, and leave it on the die for the whole time the computer is running.
I''d venture to guess that keeping the key in the on CPU cache makes it an order of magnitude harder to get than keeping it in RAM.
We use industrial VPN router / gateways that allow us to have our own certs and encryption keys. They have a digital input connected to the PLC that the customer turns on with a password protected maintenance screen on the HMI and / or a lockable key switch. The customer will call us, and we then calculate and give them the password to enable the VPN, they unlock it, and then we are able to remotely connect to the machine and service it.
Unless we have walked the customer through enabling remote access, the router is not connected to any network, and it will not respond to a ping or port scan. It has all the security of the network cable being unplugged, but we can activate it without having to lockout the machine and open the control cabinet.
These routers are very popular, and can also log access information, performance data, and error messages. There are even versions that can verify the PLC program, configuration, and databases to be sure it has not been (Stuxnetted) modified. If the firmware detects anything has been changed it will automatically reload the system from a self-signed backup contained in the router, send us an EMail with what was changed, and attach various logs.
Links:
www.mbconnectline.com/index.php/en/produkte/mbconnect24net/item/mbconnect24
http://www.ewon.biz/en/home.html
I have had factory training on these routers, and after seeing the features and interfaces, I've asked what operating system they run. Of course it's Linux, but the manufacturers do not release their source code! They would make an awesome little hackable home router / VPN / Fileserver, but they are locked down, and most have cryptographically signed firmware and bootloaders (ala Tivo) that refuse to run any modified code. Some of them will even erase themselves if they detect anything out of the ordinary going on.
I've tried to plead my case that as a buyer of that hardware I am entitled to the source code, and even mentioned that they should sell an unlocked and unsupported version to allow customers to integrate them into different applications. I always get the same answer. "These devices use OUR OWN PROPRIETARY LINUX, and we do not provide it to anyone for security reasons"
So now I am on the search (anyone???) for a BSD based (anyone???), or properly supported Linux version (anyone???) so I do not have to support the GPL violators. I'm tempted to notify RMS, I want to hack on one of these in the worst way:)
The routers have multiple VLANs that can be configured on a port by port basis because most of these systems are connected to (at least) the intranet nowadays, and it is nearly impossible for them not to be. The setpoint recipes, quality control, inventory, ordering, historical data, productivity, and monitoring of these machines is always done remotely, even if it is in the same plant.
You just configure the router to give the the device its own VPN / VLAN to the exact device it needs to connect to. Hardly anyone walks down on the factory floor to copy data with a memory stick anymore, it's too risky for the poor unpatched naked Windows installations being used. Some of them are configured to automatically connect once per hour / shift and dump their data to a central database and then disconnect, but most of them are always connected to various supervisory control systems. Most of the HMIs and data access servers are MS Windows NT / 2K / XP based, and rely heavily on MSSQL, OLE, and crappy vendor supplied closed source drivers to interface Windows to the various Industrial Networks.
Usually these old unpatched Windows machines just connect to the various databases with a specific VLAN for each one, and then the properly patched and AV'd supervisory systems (now mostly Windows 7) make their own connections to the databases and push or pull the necessary data from them without ever connecting directly to the vulnerable unpatched PCs that are actually controlling the process.
No updates or
Yet... For some reason I'll bet the app from my cable company has much better security protecting their content than all of these bank apps put together.
Just imagine if the shit hits the fan, and there are large areas without power, and / or internet access. Your Bitcoin will be worth exactly zero, as you'll have no way to cash them in.
When you flip the switch the reflecting surface changes from the polished back surface of the mirror to the front surface of the glass which is no where near as shiny.
That was funny +1
Jenny!!!
Is that you?
One day I remember going in to my Radio Shack to get a counter IC and found the whole area gone, and the manager (Steve) told me that they were clearing everything out, and not replacing it. It was all in a big octagonal cardboard clearance bin. I offered him $20 for the whole bin, and took the bin and everything home. I still have it, It's not used as much any more, but when you are thinking dang, where am I gonna find one of those nowadays, it is sure handy.
Only good for 90 days but you can relaunch virtual disk and get another 90..
All versions including and since XP
www.modern.ie/en-us/virtualization-tools#downloads
Hope it helps
Unless you made the logic gates yourself, how can you be certain your binary adder is not just an arm chip emulating a logic gate, that turns your binary counter into a satellite link and secretly shift your bits to the NSA when it detects it's not hooked up to a logic analyzer?
Upgrade your tinfoil hat man for fscks sake!
That does NOT compute!
Are you staying for Sock Hop?
If I had a nickel for every time I stuffed a quarter in that game...
Even just the times I played while wearing roller skates...
I bought an 80GB Intel X25-M about 5 years ago, and I have done nothing to give it any breaks for being an SSD. All logging, swap, cache, etc is still at default or higher levels, and I've filled it hundreds of times. It has 6 partitions on it, and I move data around between them constantly.
I have a 16GB extended partition for installing the distro of the week that has seen over 200 installs just to try them out, or test RC's for bugs, or test changes to my main install, and I copy whatever I downloaded there to another 40GB partition that I use for my shared directory. That partition has downloaded over 5TB of stuff that has been either transferred to an external drive, and/or burned to DVD. I have transcoded and remastered over 2TB of DVDs removing the junk that comes on them from Disney etc and converted them for my portable devices. I have also ripped in my 500 CD collection 3 different times at ever increasing bitrates. I take thousands of pictures in burst mode to get the right moment, and then load them all and sort through them and delete 75% of them. I shoot and edit / transcode HD videos by the GB, and I have never once given a thought about wearing out the drive (backups!) and I use it like I would any other spinning rust drive.
I finally got to 99% on the life left wear indicator as reported by SMART and I've yet to have any sectors fail and have to be remapped to the spare flash. If I can do that for the next 100 years, and still have 75% life left on the flash, I'd say it's good enough for me!
Cheers!