Concerns over RAF jet maintenance
Join Date: Jan 2000
Location: ???
Age: 59
Posts: 453
Likes: 0
Received 0 Likes
on
0 Posts
Just a snippet on the subject of outsourced maintenance. During my time involved with the heavy maintenance of “Beagles favourite” the TriStar, it was frightening how inefficient the support authority could be at managing the maintenance of just 9 aircraft. Initially it was normal to expect the aircraft to always be late out of checks at the “contractor” when on the receiving end in the RAF. It was soon apparent many of the delays had been caused by SA mistakes.
A couple of examples are an aircraft sitting on jacks after a major with no landing gear. The landing gear had gone away for overhaul to the USA on a separate SA contract which didn’t take into account a required return date. On another occasion it was only decided to carry out some detailed inspections AFTER the areas had all been paneled up, painted etc.
Not sure if the quality/efficiency has improved now the maintenance is carried out in Abu Dhabi.
What level of maintenance will be carried out by civil/military engineering on the A330K?
A couple of examples are an aircraft sitting on jacks after a major with no landing gear. The landing gear had gone away for overhaul to the USA on a separate SA contract which didn’t take into account a required return date. On another occasion it was only decided to carry out some detailed inspections AFTER the areas had all been paneled up, painted etc.
Not sure if the quality/efficiency has improved now the maintenance is carried out in Abu Dhabi.
What level of maintenance will be carried out by civil/military engineering on the A330K?
Join Date: Nov 2000
Location: South of the Fens again!
Posts: 286
Likes: 0
Received 0 Likes
on
0 Posts
...airframes that actually FLY for 16 hours a day every day, now that is a capability that I am sure the RAF would love to have!
Much has been said here about using OEMs and Design Authorities (often, but not always, the same thing).
Far more fundamental to the in-service phase (i.e. the majority of the project and where upwards of 75% of the money is spent) is the question which has to be answered up front – “Having procured a given build standard, do you intend contracting the OEM/DA to maintain it?” And remember, this process includes safety, aircraft pubs, drawings etc.
If the answer is “yes”, then a Design Authority or Custodian should be appointed and paid to maintain the build standard. No half measures.
If the answer is “no” (i.e. you are knowingly going to compromise safety and the ability of any contractor to repair kit properly), then buy the kit from any old supplier and don’t bother acquiring master drawings or source code.
In my experience, the effectiveness of DARA and their predecessors has often been compromised by the ever increasing tendency to answer “no” to this question. “No we don’t want to maintain safety”. “Maintaining safety is a waste of money”. “We don’t care if kit is repaired using documentation which is 15 years out of date and missing critical mods”. But enough of DPA’s XB and DECs, for they know not what they do. (But don’t forgive them). Experienced PMs largely ignore them anyway.
You’d be amazed at how often u/s kit can pass a standard serviceability test. That’s not a failure within DARA, but because the build standard hasn’t been maintained. Or how seldom an audit trail can be established from an actual current build standard back to the original. Name a procurement fiasco and I’ll show you problems in this area. SA80, Chinook, BOWMAN…..
Finally, I agree with Eng. Many of DARA’s problems have been self inflicted. I simply don’t agree that they should be given access to source code for the sake of it. Its duplication and wasteful. And the OEM doesn’t have to do repairs, but if you employ someone else and he’s not also the Design Custodian, there MUST be a complementary contract with whoever is the DA or DC – and there must always be an audit trail back to the OEM.
Far more fundamental to the in-service phase (i.e. the majority of the project and where upwards of 75% of the money is spent) is the question which has to be answered up front – “Having procured a given build standard, do you intend contracting the OEM/DA to maintain it?” And remember, this process includes safety, aircraft pubs, drawings etc.
If the answer is “yes”, then a Design Authority or Custodian should be appointed and paid to maintain the build standard. No half measures.
If the answer is “no” (i.e. you are knowingly going to compromise safety and the ability of any contractor to repair kit properly), then buy the kit from any old supplier and don’t bother acquiring master drawings or source code.
In my experience, the effectiveness of DARA and their predecessors has often been compromised by the ever increasing tendency to answer “no” to this question. “No we don’t want to maintain safety”. “Maintaining safety is a waste of money”. “We don’t care if kit is repaired using documentation which is 15 years out of date and missing critical mods”. But enough of DPA’s XB and DECs, for they know not what they do. (But don’t forgive them). Experienced PMs largely ignore them anyway.
You’d be amazed at how often u/s kit can pass a standard serviceability test. That’s not a failure within DARA, but because the build standard hasn’t been maintained. Or how seldom an audit trail can be established from an actual current build standard back to the original. Name a procurement fiasco and I’ll show you problems in this area. SA80, Chinook, BOWMAN…..
Finally, I agree with Eng. Many of DARA’s problems have been self inflicted. I simply don’t agree that they should be given access to source code for the sake of it. Its duplication and wasteful. And the OEM doesn’t have to do repairs, but if you employ someone else and he’s not also the Design Custodian, there MUST be a complementary contract with whoever is the DA or DC – and there must always be an audit trail back to the OEM.
Join Date: Mar 2005
Location: On the outside looking in
Posts: 542
Likes: 0
Received 0 Likes
on
0 Posts
Eng(rtd),
methinks people are confusing software maintenance (the thing that is going to cost the most to maintain on modern aircraft) with ye olde mechanical 3rd/4th line engineering, and the fact that if you don't have IPR then this 'deep maintenance' goes back to the OEM, because it's them and only them that have the 'rights' to modify the code.
rgds
sw
Why is access to source codes required for deep maintenance and why does deep maintenance have to be done by the OEM?
rgds
sw
Short Blunt Shock
Join Date: Jul 2003
Location: UK
Posts: 631
Likes: 0
Received 0 Likes
on
0 Posts
As for civilian practices in the military, the one thing that the airlines CAN do is generate airframes that actually FLY for 16 hours a day every day, now that is a capability that I am sure the RAF would love to have! What sort of surge would you require then?
The simple fact is, we no longer have the capability to generate airframes at the same rate as before - and those that we DO generate are a shambles. I have lost count of the number of sorties I have lost over this last month due to mainly minor unserviceabilities that could have easily been sorted under the old system.
Do yourself a big favour and pull your tongue out of the establishment's arse. It is because of people like you that we are in the state we are in.
16B
Registered User **
Join Date: Mar 2005
Location: Cambridge
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
Software, why's it such a problem ?
Safeware
I think some of the postings on here are a pretty good demonstration of why we have made such a mess of most procurements involving complex electronic hardware, and by implication software.
So, a hypothetical situation, our friendly OEM delivers the source code with our next shiny new jet, great, everything will be okay now, until of course we want to do something with it. So what do we need, well, just quickly off the top my of my head, we’ll need the development environment used by the developer, the requirements, design, testing and validation tools used, we’ll need the CM tools, we’ll need the documentation (SRS, SDD, STP, STR, SQP etc, etc), almost certainly a suite of CASE tools to read, understand and amend this documentation, because it won’t be on paper. Then of course we’ll need all of the different stage testing rigs (and the ability to maintain them). We will need to be able to carry out all of the VV&T activities which will be required to release this software for service, much of this software will almost certainly be safety related/safety critical, particularly as the systems arriving over the next few years are far more highly integrated and complex.
Oh yes, and now it starts to get difficult, we will need the skilled and experienced software engineers to maintain this software. But we haven’t got any ! So far we have muddled through (admirably I should add, given the constraints), reliant on the dedication and motivation of a few staff pulled from the avionics trade. We do not have, nor to my knowledge do we have any plans to have, a software engineering trade/branch. Perhaps we could use civilian staff ? But given the civil service constraints, how likely are we to be able to recruit and perhaps more importantly, retain a skilled workforce ? So what options do we have left for our software maintenance……….. ?
If you are struggling with any of the acronyms, speak to a software engineer, if you can find one.
Regards
Safety_Helmut
I think some of the postings on here are a pretty good demonstration of why we have made such a mess of most procurements involving complex electronic hardware, and by implication software.
So, a hypothetical situation, our friendly OEM delivers the source code with our next shiny new jet, great, everything will be okay now, until of course we want to do something with it. So what do we need, well, just quickly off the top my of my head, we’ll need the development environment used by the developer, the requirements, design, testing and validation tools used, we’ll need the CM tools, we’ll need the documentation (SRS, SDD, STP, STR, SQP etc, etc), almost certainly a suite of CASE tools to read, understand and amend this documentation, because it won’t be on paper. Then of course we’ll need all of the different stage testing rigs (and the ability to maintain them). We will need to be able to carry out all of the VV&T activities which will be required to release this software for service, much of this software will almost certainly be safety related/safety critical, particularly as the systems arriving over the next few years are far more highly integrated and complex.
Oh yes, and now it starts to get difficult, we will need the skilled and experienced software engineers to maintain this software. But we haven’t got any ! So far we have muddled through (admirably I should add, given the constraints), reliant on the dedication and motivation of a few staff pulled from the avionics trade. We do not have, nor to my knowledge do we have any plans to have, a software engineering trade/branch. Perhaps we could use civilian staff ? But given the civil service constraints, how likely are we to be able to recruit and perhaps more importantly, retain a skilled workforce ? So what options do we have left for our software maintenance……….. ?
If you are struggling with any of the acronyms, speak to a software engineer, if you can find one.
Regards
Safety_Helmut
Last edited by Safety_Helmut; 7th Sep 2005 at 10:14.
Join Date: Mar 2005
Location: On the outside looking in
Posts: 542
Likes: 0
Received 0 Likes
on
0 Posts
S_H
Where did you find the friendly OEM? He had some friendly employees though.
There are 10 different kinds of people in this world
.
.
.
.
.
.
.
Those that understand software and those that don't.
sw
Where did you find the friendly OEM? He had some friendly employees though.
There are 10 different kinds of people in this world
.
.
.
.
.
.
.
Those that understand software and those that don't.
sw
Join Date: Aug 2005
Location: Not Ardua enough
Posts: 266
Likes: 0
Received 0 Likes
on
0 Posts
Being one of those trained ex whatevers and having had more than my fair share of
DARA St Athan (Nice hangers but what are we going to put in them?)
BAe (RSAF scud watchers club medal, with bar)
Marshals (Now what are we going to do with all our Rover dealerships?)
I find the concept of outsourcing both laughable and laudable, it's horses for courses and without doubt certain Welsh establishments suffer/d from poor management, lack of focus etc etc Whilst other providers continue to make a decent fist of things. We generated a C130k with all the interesting bits to replace the one lost in Iraq in rapid order and that A/C was weeks ahead of schedule.
Edited for the hell of it
DARA St Athan (Nice hangers but what are we going to put in them?)
BAe (RSAF scud watchers club medal, with bar)
Marshals (Now what are we going to do with all our Rover dealerships?)
I find the concept of outsourcing both laughable and laudable, it's horses for courses and without doubt certain Welsh establishments suffer/d from poor management, lack of focus etc etc Whilst other providers continue to make a decent fist of things. We generated a C130k with all the interesting bits to replace the one lost in Iraq in rapid order and that A/C was weeks ahead of schedule.
Edited for the hell of it
Last edited by ARINC; 7th Sep 2005 at 20:27.
Join Date: Jan 2001
Location: Land of the Rising Taxes
Posts: 128
Likes: 0
Received 0 Likes
on
0 Posts
Safety_Helmut
Since 1970 we have had a Nimrod Software Team which has worked with the OEMs to ensure that we have the right software. Indeed I seem to remember that only recently, some sorce code was released to us to enable a software uodate that could be performed more efficiently at Kinloss.
Unfortunately we have learned absolutely nothing since and the MRA4 software will be totally controlled by BWOS, despite the Gin Palace built for them at Kinloss.
Its no wonder we give up and get out
Since 1970 we have had a Nimrod Software Team which has worked with the OEMs to ensure that we have the right software. Indeed I seem to remember that only recently, some sorce code was released to us to enable a software uodate that could be performed more efficiently at Kinloss.
Unfortunately we have learned absolutely nothing since and the MRA4 software will be totally controlled by BWOS, despite the Gin Palace built for them at Kinloss.
Its no wonder we give up and get out
Join Date: Mar 2005
Location: On the outside looking in
Posts: 542
Likes: 0
Received 0 Likes
on
0 Posts
Contracts
Stan,
If 'we' means the man on the ground, then 'we' have learned an awful lot - NST being a DA and HSMU being 2 examples of where the quality of the guys on the ground has shone through.
I blame it most (if not all) of it on contracts. If 'we' is the MOD, 'we' have not learned how to assess our needs and contract appropriately. Industry are (as the shareholders would expect) way smarter at getting the right words into the contract that make it easy for them to make money and difficult for the MOD to go anywhere else.
2 examples of this are C-130J and Chinook Mk3: areas where logic will tell you we need to have 'control' of how software is modified to meet the changing needs of the operators, but these areas are not 'ours' to modify.
When the J was coming into service the Aussies binned the idea of having anything other than flight safety critical updates because they couldn't afford membership of 'the club'.
sw
If 'we' means the man on the ground, then 'we' have learned an awful lot - NST being a DA and HSMU being 2 examples of where the quality of the guys on the ground has shone through.
I blame it most (if not all) of it on contracts. If 'we' is the MOD, 'we' have not learned how to assess our needs and contract appropriately. Industry are (as the shareholders would expect) way smarter at getting the right words into the contract that make it easy for them to make money and difficult for the MOD to go anywhere else.
2 examples of this are C-130J and Chinook Mk3: areas where logic will tell you we need to have 'control' of how software is modified to meet the changing needs of the operators, but these areas are not 'ours' to modify.
When the J was coming into service the Aussies binned the idea of having anything other than flight safety critical updates because they couldn't afford membership of 'the club'.
sw
Registered User **
Join Date: Mar 2005
Location: Cambridge
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
Stan
Not sure about the 1970 bit, because the MR1 is normally sighted as the classic example of an aircraft coming in with no software support. (We're not far off repeating that now by the way)
You're right though. the SSTs have performed admirably, but on mission, not safety critical software. They have been maintaining JOVIAL, CORAL 66, AYK14 and Spirit3, why, because no bugger else wanted to do it in recent years. The software intensive systems entering service over the next few years are far removed from the likes of Tornado, Harrier, Sentry and Nimrod. We simply do not have the capability for in-house support, but we should ask ourselves the question why. We have not made the commitment to have that capability, why should that be ? Software is not understood, and that should be a real worry, beacuse 80-90% of functionality is implemented in software.
In simple terms, we are now at the whim of the OEM, we have no choice, all those people who witter on about not having the source code, yes you're right, but it pales into insignificance besides not even having the nouse to realise that the the OEM has you over a barrel for the life of the equipment, and that there is virtually nothing you can do.
Safety_Helmut
Not sure about the 1970 bit, because the MR1 is normally sighted as the classic example of an aircraft coming in with no software support. (We're not far off repeating that now by the way)
You're right though. the SSTs have performed admirably, but on mission, not safety critical software. They have been maintaining JOVIAL, CORAL 66, AYK14 and Spirit3, why, because no bugger else wanted to do it in recent years. The software intensive systems entering service over the next few years are far removed from the likes of Tornado, Harrier, Sentry and Nimrod. We simply do not have the capability for in-house support, but we should ask ourselves the question why. We have not made the commitment to have that capability, why should that be ? Software is not understood, and that should be a real worry, beacuse 80-90% of functionality is implemented in software.
In simple terms, we are now at the whim of the OEM, we have no choice, all those people who witter on about not having the source code, yes you're right, but it pales into insignificance besides not even having the nouse to realise that the the OEM has you over a barrel for the life of the equipment, and that there is virtually nothing you can do.
Safety_Helmut
Last edited by Safety_Helmut; 7th Sep 2005 at 23:06.
Safety Helmut,
But is there an alternative? Given sufficient investment, commitment and motivation could the UK MoD (perhaps with ACIG) do more of its own software? Is it a capability that could be 'grown'?
But is there an alternative? Given sufficient investment, commitment and motivation could the UK MoD (perhaps with ACIG) do more of its own software? Is it a capability that could be 'grown'?
Registered User **
Join Date: Mar 2005
Location: Cambridge
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
investment, commitment and motivation
Jacko
Absolutely, But the investment, commitment and motivation can only come when those on high realise the situation we are getting ourselves into. We don't seem to have realised yet that when we can't make the changes we need to to our software, our hardware may be rendered useless.
Safety_Helmut
Absolutely, But the investment, commitment and motivation can only come when those on high realise the situation we are getting ourselves into. We don't seem to have realised yet that when we can't make the changes we need to to our software, our hardware may be rendered useless.
Safety_Helmut
Join Date: Mar 2005
Location: On the outside looking in
Posts: 542
Likes: 0
Received 0 Likes
on
0 Posts
S_H
The trouble is, for all that we have that is new, or now under contract, it is likely to be too late. And by then those on high will have retired and joined the dark side to feed off this misfortune.
sw
The trouble is, for all that we have that is new, or now under contract, it is likely to be too late. And by then those on high will have retired and joined the dark side to feed off this misfortune.
sw
