Phone: 925.456.9900 Request for Quote
Obsolescence

Pioneer in Obsolescence Management and Legacy Sustainment for embedded technology

  • Obsolescence: Too Soon or Not Soon Enough?

    Obsolescence: Too Soon or Not Soon Enough?

    It is strange how onboarding the concept of legacy sustainment can change the way you look at the world around you. On a recent road trip along one of the nation’s many two-lane highways, I found myself wondering about the thousands upon thousands of wooden utility poles dotting the landscape. How often are they repaired? […]

  • Keys to Managing DMSMS: A Clear Assessment of Obsolescence Risk

    Keys to Managing DMSMS: A Clear Assessment of Obsolescence Risk

    “Proactively consider DMSMS through[out] a system’s life cycle by anticipating potential DMSMS occurrences and taking appropriate logistics, acquisition, and budgeting steps to prevent DMSMS from adversely affecting readiness or total ownership cost.” SD-22 DMSMS Guidebook Continued from a previous post: Being Proactive While obsolescence management traditionally starts after products become mature, that is really waiting […]

  • Keys to Successfully Managing DMSMS: Being Proactive

    Keys to Successfully Managing DMSMS: Being Proactive

    “Proactively take timely and effective actions to identify and minimize the DMSMS impact on DoD acquisition and logistics support efforts.” SD-22 DMSMS Guidebook The DMSMS conference is just around the corner. As a conference all about obsolescence management, it tends to be one we look forward to every year. This year, we’re looking to take […]

  • Software Obsolescence: Why Modernization Doesn’t Necessarily Mean “Modern”

    Software Obsolescence: Why Modernization Doesn’t Necessarily Mean “Modern”

    For players in the embedded industry it is easy to forget how large the problem of obsolescence can be, especially beyond the component level. Recently, I was talking to a software engineer who had spent a year doing software modernization, as a result of upgrading a flight navigational system from the original code to Linux.

    The reasoning for the transition certainly made sense—the program was having difficulties finding software engineers who could continue to sustain programming that had been implemented during the early 1980s. While the system was incredibly robust and was considered “bulletproof,” it could no longer be supported the way it had been. Under pressure to upgrade, the program moved to Linux, which has a community that affords an active and growing resource for talent.

  • Are PCs becoming obsolete?

    Are PCs becoming obsolete?

    Recently on NPR I heard that PC sales have hit a record low.  With the growing touch screen market, even Windows is focusing their innovation and development on the tablet market and with operating systems like the recently updated Windows 8.  Bringing together the best of both worlds is the “convertible” market, where your “laptop” […]

  • COTS: A “reactive” good idea (continued)

    COTS: A “reactive” good idea (continued)

    To answer the question, we need to look at the issues of innovation from a different angle; namely economics and markets. Free markets are a wonderful concept as long as the motivation and incentives are aligned in the right way for all the players in order to achieve the set objective. So let us look […]

  • COTS: A “reactive” good idea

    COTS: A “reactive” good idea

    Following a directive from the US military in the early 1990s, the defense industry made a shift from using custom embedded electronic components made to military specifications to commercial-off-the-shelf (COTS) components.  Since the overall share of the DoD as a consumer was expected to shrink over time, this move to reduce costs took a practical […]

  • Refurbished Boards: What works today may not be reliable tomorrow

    Refurbished Boards: What works today may not be reliable tomorrow

    Saying that something is “good enough for government work” is often meant as a joke and the reference implies “mediocre work.” The irony is that “government work” is often highly sophisticated; systems are designed and engineered to operate in the most extreme environmental conditions for a very long period of time.

    I recently had the pleasure of having lunch with a talented component engineer who has spent much of his career working in the defense industry.  During the course of our discussion I learned that some aviation systems need ICs to operate in temperature extremes ranging from -55°C to 125°C; ground units often travel in harsh environmental conditions (e.g. fighting extreme heat and sand storms in deserts) while being exposed to hostile attacks; satellites traveling through orbit are exposed to protons and heavy ions from solar flares, yet must operate reliably in space.

Newsletter Signup