{"id":7719,"date":"2015-02-25T13:00:06","date_gmt":"2015-02-25T13:00:06","guid":{"rendered":"https:\/\/www.techdesignforums.com\/practice\/?p=7719"},"modified":"2015-02-25T12:25:52","modified_gmt":"2015-02-25T12:25:52","slug":"254-without-tears","status":"publish","type":"post","link":"https:\/\/www.techdesignforums.com\/practice\/technique\/254-without-tears\/","title":{"rendered":"DO-254 without tears"},"content":{"rendered":"

At first glance the DO-254 aviation standard<\/a>, \u2018Design Assurance Guideline for Airborne Electronic Hardware\u2019, seems daunting. It defines design and verification flows tightly with regard to both implementation and traceability.<\/p>\n

Here\u2019s an example of the granularity within the standard: a sizeable block addresses how you write state machines, the coding style you use and the conformity of those state machines to that style.<\/p>\n

This kind of stylistic, lower-level semantic requirement \u2013 and there are many within DO-254 \u2013 makes design managers stop and think. So it should. The standard is focused on aviation\u2019s safety-critical demands, assessing the hardware design\u2019s execution and functionality in appropriate depth right up to the consequences of a catastrophic failure.<\/p>\n

Nevertheless, one pervasive and understandable concern has been the degree to which such a tightly-drawn standard will impact on and be compatible with established flows. This particularly goes for new entrants in avionics and its related markets.<\/p>\n

Your company has a certain way of doing things so you inevitably wonder how easily that can be adapted and extended to meet the requirements of DO-254\u2026 or will a painful and expensive rethink be necessary? Can we realistically do this?<\/p>\n

Here\u2019s the good news. The demands of the standard map closely to how EDA tools have developed and continue to evolve. Automation therefore takes a lot of pain out of the process.<\/p>\n

DO-254 and EDA in harmony<\/strong><\/h2>\n

At Real Intent, we have just placed DO-254 at the forefront of the new release<\/a> of our\u00a0Ascent Lint<\/a> tool. It is a good illustration of what I mean.<\/p>\n

First, what is a linter if not largely an accumulation of design knowledge that is applied to a new project in the light of what has been discovered on earlier ones? That\u2019s where most of the rules come from. This has obvious and very beneficial implications for designs that observe predefined coding styles.<\/p>\n

Our lint tool can guide you to the right places to look. When you have that information, it becomes a lot easier to adapt your flow and your design practices.<\/p>\n

But let\u2019s go further and look at the philosophy behind DO-254.<\/p>\n

Consider the implications of \u2018complexity\u2019. It may be the most overused word in EDA but it\u2019s still true that the increasing challenges faced by electronics system design have seen more intelligence fed into tools of all types.<\/p>\n

To achieve DO-254 compliance specifically, I would argue that a linter is an important foundation, but you need to go further. You need a suite of tools, also packed with the same kind of semantic intelligence.<\/p>\n

The kind of hierarchical RTL verification offered by our Ascent IIV<\/a> tool and the depth of understanding of unknowns within our Ascent XV<\/a> X-verification tool illustrate the extra checks and traces that are likely to be needed for a safety-critical design.<\/p>\n

And there they are already in our tools \u2013 and yes, those of some of our competitors. These tools have evolved largely in parallel with the needs of this particular standard, but more importantly with the broader needs of all electronic system design.<\/p>\n

Processes alone can only take you so far. Processes that highlight the need for an informed approach to design are what we need. That last quality strikes me as a key and very welcome aspect of DO-254.<\/p>\n

DO-254 has its rewards<\/strong><\/h2>\n

None of this means that DO-254 compliance is \u2018easy\u2019. No safety-first design should be. Attention to detail matters. But again, you already knew that even if you have never worked on an aviation project before. Today, nothing is easy.<\/p>\n

In that context, today\u2019s EDA tools include capabilities that greatly improve the efficiency with which existing players in aviation deliver projects and also lower the barriers to entry for new ones. That boosts competition and thereby quality.<\/p>\n

Right now, aviation is an exciting field. The drone market alone \u2013 spurred by interest from the likes of Amazon and Google \u2013 is being awarded multi-billion dollar valuations. In the US, the FAA has this month finally described how it sees UAVs operating, albeit relatively small ones for now.<\/p>\n

As UAVs become more commonplace, their DO-254-compliance will increasingly be required… even if the FAA is not itself making that mandatory. Yet.<\/p>\n

A tremendous opportunity exists and EDA can help a great many of its customers take advantage of it. DO-254 does present challenges, but they are not so different from those we already face \u2013 with the right tools you can adapt without tears.<\/p>\n","protected":false},"excerpt":{"rendered":"

Compliance with aviation\u2019s hardware design standard is seen as a \u2018tough ask\u2019, but EDA\u2019s own evolution has made that process easier than you may think.<\/p>\n","protected":false},"author":138,"featured_media":4407,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1683,1007,1010,1550,1063],"coauthors":[1441],"class_list":["post-7719","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-design-verification","tag-aviation","tag-avionics","tag-do-254","tag-lint","tag-standards-2","workflow-expert-blog","workflow-op-ed","workflow-up-to-date","organization-real-intent"],"_links":{"self":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/7719","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/users\/138"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/comments?post=7719"}],"version-history":[{"count":0,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/7719\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media\/4407"}],"wp:attachment":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media?parent=7719"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/categories?post=7719"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/tags?post=7719"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/coauthors?post=7719"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}