Tired of arguing with suits? Get ready to argue with engineers! Since time immemorial, IT professionals have been told they must serve their employers by delivering infrastructure that ensures both uninterrupted operations and delivers competitive advantage within moments of a new product or service being imagined. The reality is rather messier, leading to endless commentary to the effect …
So mechanical and electrical engineers may need to communicate about detailed product requirements with software engineers.
And the answer to this "problem" is provided by a bunch of non-engineering suits from Gartner?
From where I am sitting, there is not much of a problem when engineers communicate with one another. It's when suits enter the system, in any guise whatsoever, that the grief really sets in.
Agree, and I work specifically in this field. It's not that hard - the heavy machinery is well-known to be inherently insecure, so you keep it behind a layer of indirectness or three. I know enough of heavy machinery to know they can't really be secured, they know enough about IT to know there's hostile traffic, we set the whole thing up so that the heavy machinery is well shielded. Problems arise when someone thinks it would be really cool to be able to run their factory from their smartphone, or when they don't want to spend a single extra buck on making the design secure, or when they feel that having to enter passwords is an unacceptable drag on productivity.
Problems arise when someone thinks it would be really cool to be able to run their factory from their smartphone, or when they don't want to spend a single extra buck on making the design secure, or when they feel that having to enter passwords is an unacceptable drag on productivity.
In one simple word: MANGLEMENT!!!!!!
>So mechanical and electrical engineers may need to communicate about detailed product requirements with software engineers.
No, they are mostly already doing that and doing it very well. The problem is they will now have to involve mainstream 'IT' people who in the main have little or no real engineering experience or understanding of Software Engineering.
I wish I could upvote a hundred times, I couldn't agree more. The whole world would be such a more efficient, profitable and happy place without the buzzword spouting suits and marketeers desperately drumming up a consulting industry that nobody wants or needs (except others of their ilk).
"...IT departments... a new stakeholder... operations folks and engineers responsible for heavy machinery... butt helmets with engineers... IT will need to understand what engineers and operational technologists..." etc. etc.
What crazy book of nomenclature is this from ? These kind of ignorant terms for the technical world are rarely heard outside of the Radio 4 Today studio. Engi-what-now?
This new conversation may show IT in a good light, Steenstrup said, because IT shops have better software development processes than those in operations.
It's hard to comment on such wooly language, but the speaker appears to think that (if we take Ford Motors as an example) the powershellers in IT are better at programming than the C++ software engineers designing the adaptive cruise control for the next Fiesta. I give up.
It's hard to comment on such wooly language, but the speaker appears to think that (if we take Ford Motors as an example) the powershellers in IT are better at programming than the C++ software engineers designing the adaptive cruise control for the next Fiesta. I give up.
I believe it's more along the lines of the engineers writing software without regard for common IT practices. For example, I work at a University and we are constantly butting heads with the companies who write the various software packages that drive our scientific instruments. We want to restrict our users to prevent them from hosing their machines but the instrumentation software requires the users to run as a full administrator (sometimes this is a legit requirement) or it can't be run on a computer joined to an Active Directory Domain (why should it care?) or it wants to store temporary data in its install directory or someplace equally silly.
I've been told before by companies that their software requires that the firewall and antivirus be completely disabled and that the administrator account has to have a blank or insanely simple password (so their field techs can make updates of course.) I presume this makes sense to an engineer, but it makes me want to scream.
"I presume this makes sense to an engineer, but it makes me want to scream".
Please don't presume any such thing. If I might be permitted to adjust your statement slightly, "this makes sense to the PHB, but it makes Dilbert/Alice/Wally/Asok/anyone remotely qualified want to scream".
>but people putting the blast furnace (or whatever) on the Internet gives me a serious case of the heebie-jeebies.
But that is only part of it, suspect that IT will mandate the use of Windows as the control system's OS... says he thinking of the infamous 1992 London Ambulance Service Computer Aided Dispatch System failure...
> suspect that IT will mandate the use of Windows as the control system's OS
I hope so. Going with the most resilient and trusted operating system in the world has got to be a good idea.
> thinking of the infamous 1992 London Ambulance Service Computer Aided Dispatch System failure
That system worked exactly as it was configured to, which was overly proscriptive. The failure was not a fault of Windows, but of the people who implemented a system on top of Windows.
Windows itself proved to be an admirable platform on such a scale and continues to go from strength-to-strength for major deployments.
> the implementor proved beyond reasonable doubt was well beyond the capabilities of Windows back then...
Incorrect. Windows was perfectly capable of dealing with the load. The application running on top of Windows couldn't. You can't blame Windows or MS for someone else's mistake.
I am assuming you are some Linux fanboi; even if they had opted for that it would still have failed because the APPLICATION was poorly implemented.
>You can't blame Windows or MS for someone else's mistake.
I wasn't!
I implied, like 'The BigYin' did with the Internet (IPv4), the use of Windows (desktop) platform as the basis for the control system of a blast furnace, something with a design life of 15~20 years, was a highly questionable. However neither of us put it beyond the ability of an 'IT department' to mandate their use.
[Aside:
What will be very interesting is seeing what platform EDF uses for the core control systems in the new generation of UK nuclear reactors, particularly as effectively HP have killed off the PDP-11 and RSX-11M, even though GE Canada will be using this platform until at least 2050... Plus how they handle the maintenance of the development and maintenance environment and it's link to the live environment.
What many forget or are unaware of, is that back in the late 70's and early 80's the companies working in largescale engineering such as GEC & Plessey ran their own IT engineering departments that designed hardware and wrote OS's etc., so that they could provide multi-decade support for these very large systems. In the 80's things started to change and companies started to use third-party off-the-shelf platforms such as the PDP-11 etc.]
With respect to LAS, yes the (technical) problem was down to the designers decisions on the way they chose, rather ambitiously, to use the Windows (3.n) desktop platform, which in part can be attributed to their lack of knowledge and experience of large real-time dispatch systems (I know I'm vastly over simplifying and omitted the contract being awarded wholly on the basis of least cost etc etc). Hence the connection with the 'IT department' mandating a software technology for an engineering problem that isn't really appropriate, because the engineering application is outside their normal experience.
And yes the designers did show the limitations of the Windows (3.n) platform, that wasn't a bad thing, as it gave us some useful information to help guide the design of similar types of systems that successfully incorporated Windows desktops.
Damn straight. The concept that every freaking thing in the world would somehow magically be better if we just added some AJAX to it is idiotic. The truth is management is constantly in an idea crisis - they never have any. So, they chase the next shiny object or fad hoping that if they get lucky then revenue will magically appear and they can look like heroes without actually doing anything.
Worrying over the people who actually KNOW how the business works (engineers and IT) working together is just another management CONsultant trying to justify his next overpriced contract.
> the suppliers of heavy equipment sell sealed-box products that are sold as just working.
And if only more IT kit was like that.
The most reliable kit in most datacentres is that insignificant little box in the corner that runs a dedicated application on top of NT, or Solaris 6. Nobody knows how it works, they just know that the supplier "deals with it" and won't allow anyone else to log in, upgrade the hardware, touch any of its cables or sometimes even reboot it. It has been there since Y2k (or beyond) and just works.
The secret to these boxes is that they are dedicated: they do one thing only, have zero flexibility and no scope for alterations or customsation. But when they are properly designed, from a sensible specification that was implemented by capable people and neither over-sold nor prematurely released (before testing AND bug fixing had been completed) then they are world-beaters. No Patch Tuesdays for them!
However, we IT people aren't used to systems that are stable. We assume that everything arrives broken and that it's 3-5 year lifespan will be spent working around its shortcomings and trying (often: failing) getting it to meet the specification that was originally written on the brochure that the CIO saw, read and bought. The best we can hope for is that these "heavy equipment" manufacturers place as much store in the reputation of their software products as they do in their hardware, and also that they are steadfast in their demands that unqualified IT people don't go anywhere near it.
The difficulty is that to get rock-steady systems, you will never be talking about being at the leading-edge. Instead of implementing the latest and greatest stuff that comes out of a 6 month-old startup (soon to be a 7 month-old foldup or sell-out), the secret will be to not even look at tech that isn't a few years old, has got some thousands (or for the IoT: millions) of units delivered and working and to never, ever make any changes to the thing's external networking environment once it's been installed.
If that means we're going to have to start getting things right at the first attempt and then not changing them, so be it. it can be done - just ask the makers of all those little boxes in the corner.
>The problem comes when the supplier goes bust.
In my experience the problem isn't when the supplier goes bust, but several years later when that box in the corner that everyone has forgotten about fails and the telephone number for maintenance and support on the label has been re-assigned to a totally unrelated organisation or someone's home...
I have been told very amusing story (reputable source from the company - although I have no reference), about an IBM building being decommissioned in New York (state). A quietly chuntering machine was found in the basement - origin IBM, purpose unknown. After many days of fruitless enquiries they shut it down. Promptly the local sub-grid on the power died. Not a problem of single use (except that it had probably been doing a very efficient job), just one of documentation.
"And if only more IT kit was like that"
It was... in the Soviet Union and/or any other communist state (I don't include China among them).
In a free market economy, where businesses compete against one another for a share of available money/resources, IT is an essential way to get an edge over ones competitors necessitating a balanced portfolio comprising trailing edge, leading edge and bleeding edge technologies.
That's great until somebody discovers that NT4, or XP or Solaris2.0 has a security bug and this box is on the net.
Then you have a choice of applying a fix (if one is available), trying to make the app run on a new OS, or being pwned by every script kiddie on t'internet.
There are 6502 based machines running complex machine instrumentation systems that are responsible for processing/finishing aircraft turbine blades. I know cos I was responsible for much of the design and implementation of one model 20+ years ago and was recently asked to give some expert advice on the data gathering and potential instabilities at edges of the operating envelope. I believe the company sold at least 300 of them around the world.
This development could lead to a whole new series of BOFH plots. Remote access to heavy kit and power stations yield many new opportunities of <KZZZEEEERT>, <CRUNCH>, <SLAM>, and <CLUNK>, effects, after the usual <clickety, clickety>
Beer, coz Simon and the PFY are off to the pub
I'm in engineering , well robot controlled manufacturing using a variety of machines to achieve the company aims....
There is one phrase I use over and over whenever the twits in charge go on about 'networking' the machines or 'having them on the internet' and that is "Air gap"
The machines either run a custom OS in the case of Fanuc controls, something called HerOS running on top of a linux OS in the case of the Heidenhain controls, or a custom OS running in Windows CE in the case of the Citizen machines.
All are stable and about the only ever failures are the occasional HDD failures due to vibration.
All of the machines have no firewalls, or A/V software and in the case of the Heidenhain machines, there is a specific phrase saying "We will not pay out any damages if unauthorised software is installed in this machine".
This is especially important because with the right malware, you could bypass the safety lockouts when we have the doors open, and start moving the tables/tools around..... not good if you're a tech stuck down the back of the machine tracing an electrical fault on a limit switch...
So they never get connected and the guy who did install mobile phone software and turn on the wireless networking on the company PC we use for the CAM system had his arse slapped.
Boris
Wheres the f***ing idiot icon?
That is a no argument situation. Unlike the suits, engineers know how to express requirements and can talk technical without sounding like moronic 3 year olds who think Star Trek is real. I used to work writing production line control systems and engineers are a dream to work with. I'd take engineers as customers over a board room of suits any day.
Beware of engineers, I've also worked with structural engineers automating their calculation of beam loads, previously done in Excel. It was almost close to impossible to get them to explain what the spreadhseet was doing, they had developed it years ago and forgotten about all of it. So it was a lot of trial and error and cross checking with the spreadhseet instead of what you'd supposed to get from engineers, that is, clear specs.
Their faces when I discovered an error in the spreadsheet they were using in many industrial buildings was something to watch. Fortunately the error was on the right side, that is, they were building stronger structures than they thought. That's why they have testing, right?
I do Process Control.
I do Remote Support.
Sometimes the IT guys are my best friends; helpful & prepared to learn that a Process system with a life expectancy of 15-20 years is NOT going to do WIndows upgrades; nor is it going to arbitarily shift from its current OS (which could be DOS or later) just because of some new fad from MS. They work with me (& my colleagues) to get it working. Wow; I could almost love them.
Then you get the IT department that RUNS - but still interfers (without asking or checking; blowing a badged CISCO router back to Cisco firmware and trashing all the automation preferential stuff that our Cisco firmware handled correctly; and then crying 'cos the Production manager screamed at the dozy idiots).
Then you get the ones who shove their damned group policy/ arbitarily changed service account name rules onto production servers crashing entire factories. Oh yes; the service account that looked after the SAP connector; just changed; just like that; 3 days loss of production -- moroons. Not even one of their servers.
Then you get the corporate supplier of all things server based; who don't even know how to maintain an SQL server. Tell our clinet they will have to charge them for even looking at the problem they have caused - then having the damned nerve to ask US to inspect their cock up and help their cleint for free; Holy Pisstake; if I wasn't talking to the factory IT guy ( one of the many good guys) about why I thought we were justified in saying NO WAY - and he agreeing with me; I would not have believed what I was seeing/hearing.
Then you get the moroons in OUR IT trying to get a VPN through the moroons in the CLIENT'S IT. Lock them all in a room with no food or water until they sort it out is my answer. How long to fix a site to site VPN you may well ask - try 3 to 6 MONTHS.
And when it comes to running Process Control in VMWare - I've been told by the IT people in a UK factory the ONLY VMWare servers are in the US; and yes please can the DCS run on VMWare servers in the US. Of course bloody well not; IT people ?
Guys - Process Control is NOT the same as Windows Office; or even SAP. And NO we can not test every piece of fixit code that comes out of MS and tell you it will work with ALL our kit. Especially if you work in Pharma or Food & Drugs.
We like to LOCK it all down when we've finished building it. And your factory Process Engineers get kind of antsy when some idiot comes along to fiddle with something that's been working for weeks/months/years.
And since your factory techs & Egineers no longer specialise in our kit; they expect us to remote in & help them fix problems. SO it really is a no brainer - we must have remote access - via a nice secure VPN with proper passwords and proper accounts; of course; what do you think ? That we're as stupid as the damned suits ?
Please remember that if the factory is not making widgets; there is no need for all that back office IT that keeps you employed. So no; I'm afraid 'my' process network is way more important than your network; and no; I do serriously expect to PUSH my data out to your servers and suck your data in; even when I'm playing on the Middleware box.
Please help us to help you; and remember - the devs who make our software ARE Rocket Scientist when it comes to process programing; and don't have time (because we also have stupid suits making impossible demands on us) to pander to the latest IT craze/good idea/sensible recommendations that have just surfaced to replace the last bright ideas the last head of IT had.
And no; I can't make that DCS running on WIndows 2k run on W2k8; it's going to cost £500 000 to £1 000 000 to make that happen - something your company can't afford to do (what with paying some incompetent 3rd party IT 'support' company to break Process servers by pushing unquallified patches on them).
Most of us want to work with you guys in IT to help make BOTH our companies money. We (well most of us) aren't IT specialist (though we've had to learn a lot); most times all we want is a little help and advice; and an understanding that we are trying our damdest to get YOUR factory working efficiently & profitably. So maybe it really is YOU who should be discussing possibilities with YOUR Process Engineers & Techs.
Let's just work together - looking after our mutual client; resolving issues in a nice flexible way. We are not your enemy; honest !
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
