Edge processing architectures in today’s autonomous and AI military systems, process an ever growing amount of sensor data. Many of these systems or devices used for edge processing applications in forward-deployed environments need to be small, rugged and agile. To handle this extreme workload, system architects must design boards using the fastest field-programmable gate array (FPGA) devices and multicore processors. These devices cannot provide peak performance without massive amounts of high-speed DDR4 memory for resident data and real-time execution. Faced with additional challenges, the system architect must design these systems to meet the size, weight and power (SWaP) constraints of smaller, more agile edge processing platforms integral to our warfighters’ mission success. To support the system requirements, each embedded board within the system could need a minimum of 64GB of memory per processor, equating to more than 128 separate commercial-grade memory devices or multiple dual inline memory modules (DIMM), for layout on a printed circuit board. This is not a feasible solution for the embedded boards at the core of ultra-compact edge processing architectures in military systems operating in harsh, forward-deployed environments. Instead, high-density, military-grade memory manufactured with state-of-the-art 3D packaging technology must be utilized for space and power savings, while maintaining reliability in harsh environments.Read More
Arriving on the scene at le Bourget today, was akin to being immersed in the first sketch of a pointillist painting dotted with “hi-vis” yellow and orange safety vests. Those wearing them are the smart, safety-conscious people who are working to get the 53rd International Paris Air Show ready for launch (pun intended). It doesn’t look like much now (truthfully, we’re struggling to fathom how it will all come together in time), but by Monday, thanks to the long days and all-nighters of talented carpenters, electricians, plumbers, heavy equipment operators, IT/AV professionals, security and law enforcement officers, among many others, it will be spectacular, fully realized Seurat of 142,000 professionals blending together to create their own Sunday Afternoon at Le Bourget.
Our exhibition space (Hall 4, stand B41) will be host to myriad flight-safety assurance offerings including the ROCK-2 mission computing platform, as well as our esteemed Mercury ground team, nine GIFAS delegations and in our conference room, upward of 50 meetings with both existing and prospective customers and partners. Stay tuned for daily updates and a vlog or two so you can share in the action of the Mercury stand!
Although we all love connectivity and the benefits it brings us, there is a downside. By now, we’ve all heard about cars that have been hacked. Wired magazine even has an entire section of their website dedicated to the subject. Anytime you connect to a network, you open up your system to vulnerabilities.
Avionics systems are the same. These critical systems operate our airplanes, helicopters and airborne unmanned vehicles. Everything is moving to digital and they are increasingly being networked.
Historically (despite the recent 737 max 8 incidents), avionics systems have been remarkably safe – much safer than driving. One example of this can be found in this USA Today article quoted below.
“In absolute numbers, driving is more dangerous, with more than 5 million accidents compared to 20 accidents in flying. A more direct comparison per 100 million miles pits driving’s 1.27 fatalities and 80 injuries against flying’s lack of deaths and almost no injuries, which again shows air travel to be safer.”
How has air travel achieved such safe success? Through very diligent design methodologies combined with testing and verification procedures. These procedures are captured in the certification process known as DAL (Design Assurance Level). And the intensity of the testing and compliance depends on the system involved as noted below.
There are two components of this process, one for software and one for hardware:
The move to digital
But now the world is changing. These platforms are being networked for a number of reasons:
- Connections to satellites for flight information, on-board entertainment and more
- Nose-to-tail connectivity
- Increasing use of AI and machine learning algorithms
- Predictive real-time system monitoring
Even when a plane isn’t flying, it gets connected to testing equipment that receives updates through the internet. Any of these networks can introduce security issues.
Add to this, there is a push for open system architectures. For avionics, FACE is one of these important design paradigms. The goal of FACE is to make military computing more robust, interoperable and portable through use of a common operating environment.
So now design engineers need to balance the needs and requirements of safety with open architectures and security. Here are a couple of recent articles on the topic:
- From Military Embedded Systems magazine:
Military aircraft avionics face new data-processing and security demands
A few trends are emerging in military aircraft avionics – including a continued push toward large touch-screen displays, as well as a migration to multi-core processing, open architectures, and a new focus on improving cyber resilience.
- From Military & Aerospace Electronics magazine:
Safety- and security-critical avionics software
Functionality of avionics software continues to expand. Additional software capabilities bring many more lines of code, and greater opportunity for error. At the same time, the more critical an avionics software suite becomes, the higher its risk of cyber terrorism and of being hacked, so current and future avionics software offer safety and security through software development tools, testing and verification utilities, and operating systems that are tamper-proof.
What to do?
Mercury has invested in security for defense electronics for many years. We have designed techniques to detect and prohibit intrusion to key systems. Combined with our avionics safety capabilities, we are uniquely prepared to address the convergence of safety, open architectures and security.
Listen to this podcast
Scott Engle, Business Development Director for Mercury, was just interviewed for a podcast entitled Wheels Up! In this episode, Scott talks about the coexistence of safety and security in world of avionics and why the key to security in aviation may be tied to the reclassification of security-related failures.
And to learn more about secure design and manufacturing, read our recent whitepaper entitled: Next Generation Defense Electronics Manufacturing
“Volunteers do not necessarily have the time; they just have the heart.”
– Elizabeth Andrew
On a rainy March day, 5 Mercury employees based in Andover trekked into Boston to participate in our first Boston City Year volunteer event. Cutting a wide swath across functions (HR, Engineering, Marketing, and IT) we represented Mercury with a good cross section of the company.
City Year, a part of the Americorps national service network, strives to place college graduates, who commit to one year of service, in schools throughout the country. Their mission is to support at risk children based on 3 key indicators: attendance, poor behavior, and failure in math and English. Through “near-peer” relationships, City Year members work to provide academic and social-emotional support.
Our role was to support the City Year members any way we could so we made pencil and pen holders that would be part of an MCAS kit students would receive. With duct tape in every color imaginable, the competition was on.
After our shift was over, it was time for lunch and to talk about future volunteer endeavors. I think we all had almost as much fun talking about our different day jobs as we did volunteering. Many thanks to the Andover Engagement Team for their support and to Emma Woodthorpe, CHRO, for her advice and guidance.
If you have a volunteer idea, make sure to contact your Site Engagement team and get their support. Start small and just get out their and do something. Remember, big things often have small beginnings!
In military environments, seconds can be the difference between life or death and mission success or failure. A soldier in hostile territory needs their mobile system to rapidly process sensor data to accurately analyze threats and take action. Intelligent sensor systems using artificial intelligence (AI) to make automatic critical decisions without human intervention rely on sophisticated algorithms to process sensor data real-time at the point of generation to ensure a rapid and accurate decision can be made. This real-time processing of data at the point of generation and consumption, decentralized from a data center or the cloud, is Edge Processing. Each local system or device at the “edge” is self-sufficient to collect, process, store and disseminate data into action enabling the intelligent sensor and effector mission systems our military needs to carry out daily operations. These systems that enable mobile computing and artificial intelligence could be part of an unmanned aerial vehicle (UAV),unmanned ground vehicle (UGV) or a base camp collecting surveillance data of its surroundings to warn of incoming threats.
In my prior three posts, I provided an overview of encryption key fundamentals and the various encryption key mode strategies that can be implemented in a Mercury secure SSD. If you did not read those, stop everything and go back to them now! Or, stay here, keep reading and you’ll find a simple, easy-to-use process flow diagram to guide you to the best key management mode for your application.
It is important to note, these are only general guidelines. If you have questions or doubts, consult with a security implementation expert. In this entry, I will also share our new key management mode for secure boot which is under development and releasing soon.
The first question to ask when getting started: will the data be stored on an end user device for a CSfC-approved implementation? If so, the key management mode options are limited to either Mode 1 or Mode 6. If the program is a black key program, Mode 6 is required.
If your data storage implementation is not intended for the CSfC program, answering these questions below will help in your decision:
- Is data recovery after key purge required? The answer to this question determines whether you need a self-generated key (Mode 1) or a user-generated key (Modes 2 through 6).
- Is the program a black key program? If so, Modes 5 and 6 are appropriate. Mode 6 includes an ATA password authentication, which is recommended unless there is a specific justification to avoid doing so.
- If not a black key program, is automatic key purge beneficial or required for the mission? Session keys provide automatic key purge when power is removed from the device.
- Is the added security layer of an ATA password required for the specific security implementation? If unsure of the answer to this question, it is best to err on the side of caution and implement an ATA password.
In the first two posts of this series, I reviewed fundamental terms and concepts of encryption key classifications and discussed roles of passwords versus keys and hash algorithms. In this post, I will provide detail on each key management mode available on a Mercury secure SSD, not all of which may be supported by other SSD manufacturers.
Encryption Key Modes
While the complexity of implementation increases from one mode to the next in the following discussion, end user responsibility also increases. It is imperative to ensure that end users have the proper knowledge, training and infrastructure to successfully create, store, protect and distribute encryption keys and passwords. With these capabilities, the flexibility and security benefits of the more complex modes can be fully realized. Read More
In my first post of this series, I explained terms relating to encryption keys and the standards that exist governing encryption key algorithms. Now I will spend some time on ATA passwords and how they correlate to encryption keys.
Clarifying the Functions of an Encryption Key and ATA Password
The role of an encryption key is commonly confused with the role of an ATA password.
The only purpose of an encryption key is to convert data to cipher text so it is illegible to anyone accessing the data without proper authorization and to then decrypt data back to plain text.
A few months ago, Mercury partnered with the Society of Women Engineers to host our first Women in Technology Night at our headquarters in Andover. I was fortunate enough to have panelists Star Dargin, CEO of Star Leadership and Susan Macchia, Senior Manager at Endeavor Robotics join me in giving insight on our career progression, experiences, and steps taken to earn leadership roles. I was thrilled to see a room full of participants networking and hearing our stories, as well as an engaged audience on our livestream and Facebook Live.
I walked away from this event thinking more about two important topics: women in STEM (Science, Technology, Engineering, and Math) and work-life integration.