Electronics Obsolescence - MIL STD 1553 & STANAG 3838

MIL STD 1553 is a multiplexed data bus which is a COMMAND RESPONSE network allowing one controller, up to 31 terminals and a bus monitor on a dual redundant data bus using shielded twisted pair cabling, operating at 1MHz, with a theoretical bandwidth of 1 Million bits per second, very slow by Ethernet standards.

MIL STD 1553 has some nice characteristics for military and possible safety critical applications:

• Deterministic, each COMMAND RESPONSE sequence is timed
  and all transfer times and responses are known for each command type.
• Dual Redundant operation, the Bus Controller may transmit on either bus but not simultaneously. However, Remote Terminals and Bus Monitors can listen on both redundant buses.
• The Bus Controller continues even after detecting errors on the
  bus forever.
• There is no connect retry experiences as seen in Ethernet Technology.

MIL STD 1553 or STANAG 3838 the NATO equivalent is implemented on many electronic form factors and is typically used in Military land, sea and air platforms. 1553 is also used in the test and simulation market and is now used on the Airbus A350, so it has many varied applications. However, 1553 is a very expensive data bus technology when compared to CAN Bus for example.
I'll talk some more about 1553 in another blog soon... Alternatively, sign up at www.solutionconcepts.co.uk for our news letter.

There are many 1553 boards in existence, especially on aircraft systems, where the aircraft have been flying for 30+ years. These 1553 boards are typically based around COTS or PC form factors, the older technology includes PMC(first generation), ISA, VME and PC104. Some of these technologies are being or have been phased out, which is a big problem!

These 1553 boards are based on either an 1553 ASIC chipset or a custom FPGA with 1553 IP core, implementations vary, as some 1553 COTS vendors additionally use a DSP or even an FPGA to communicate with a 1553 ASIC chipset, there are many designs of boards with different pin-out configurations and very different software interface libraries. Thankfully, the 1553 data bus has defined cabling and interconnect specifications!

So we can see that there are already a few headaches for system designers and maintainers, when these 1553 products are pronounced "End of Life", but what can be done without redesigning hardware systems and system software to accommodate new designs or a competing product?
There's a lot of software effort required that's for sure, as most COTS vendors are electronics companies and they don't like changing their software libraries to suite individual customer's need...

I have been evolving a COTS 1553 obsolescence solution for over one year now, having worked for COTS suppliers, I could see the problems that customers are facing year after year...

In my next Blog I'll discuss my legacy 1553 solutions and provide detailed processes and methods of implementation to future proof 1553 and other technologies, such as AFDX.

By the way, these solutions could easily be applied to other technologies, so please feel free to talk with me about your problems. You can see reach me on LinkedIN, Facebook and Twitter.

If you need help now, then talk to Bob here bob@solutionconcepts.co.uk or visit Solution Concepts.

If this Blog interests you, please leave a comment!

Electronics Hardware Obsolescence - The Problems...

Electronics hardware components or even hardware system obsolescence is a recurring event, it is always going to happen, as the clock ticks on into days, months and years of component and system life. At least we know that obsolescence is going to happen to us in the future, or do we forget about it until it happens?

There could be a number of situations where electronic hardware obsolescence is affecting your project or the system that you have either designed, maintained or perhaps you're redesigning to replace an old system, incorporating newer technology, more bandwidth.

Some of the issues that you will come up against are:

• Pin compatibility, either from an electronic board or system chassis.
• The technology has ceased to exist or will not exist soon.
• The backplane technology has insufficient bandwidth for new system requirements.
• An electronic board component has ceased to exist, with no other replacement available.
• A COTS provider has changed board designs or  longer manufacture the board  that you might use.
• The Operating System is no longer supported or a kernel change will not work with your drivers.
• The electronics hardware supplier has provided a new and different software library.

In the world of COTS providers there are standards for VME, cPCI, VXS, VME, ATCA, Micro TCA and others. However, there are no standards on how the boards and IO should be interconnected together. Therefore, most COTS vendor designs their chassis, processor and IO boards in a proprietory manner.

My next BLOG will look at how obsolescence issues might be analysed in order to find solutions for the future.

You can contact me directly at Bob@SolutionConcepts.co.uk if you would like help or advice on your electronic obsolescence or legacy project. Alternatively, take a look at our web site www.solutionconcepts.co.uk

If you have a topic that you would like me to talk about, please contact me to discuss, I'll be more than happy to share my experience and expertise.

Hardware Obsolescence - EOL

Life these days is very dynamic, nothing is guaranteed anymore, as we all know. The days of a job for life are well and truly gone... Bigger companies keep acquiring smaller companies and as a result people and products get canned, which is bad news for everyone.

So I have been looking at legacy hardware problems in the market place, knowing that most of the electronic board suppliers, well at least the MIL AERO companies that I worked for, typically would not offer to provide new software, but normally insisted that you, the customer, rewrite your software for the new hardware, which will most likely be End Of Life in another FIVE years!

As we all know in the software world, changing software means extra cost in resource to design, implement and test. It's possible with a safety critical system that some certification effort will be needed, which is very costly, all for a board costing a few $1,000 dollars...

Sound Familiar?

What's the answer?
Next I'll talk about some cost effective answers to these legacy issues.