Archive | July, 2018

Brazil Safety-Critical Training Week, September 10 – 14, 2018 (Both Free & Paid Training)

23 Jul

Brazil’s largest full week of safety-critical development training is just six weeks away – hope to see you there!

Free Safety-Critical Software/Hardware Seminar, Sept 10, 2018: 

Theme: “Electronic complex and embedded software in critical systems”

Location: Technological Park of São José dos Campos, SP – Brazil

Date: September 10, 2018

Ticket price: FREE

Speakers:

  1. Vance Hilderman

CEO of AFuzion and specialist in software and systems development, with a focus on “safety-critical” in the aerospace and automotive sectors;

  1. Gilberto Trivelato

CEO of Seamax Aircraft and specialist in development of safety-critical control systems with aeronautical certification levels;

  1. Two other highly specialized specialists related to the theme.

 

Formal DO-254 Intermediate Avionics Hardware Development & Certification Training

Date: September 11-12, 2018

Location: Technological Park of São José dos Campos, SP – Brazil

 

Details:

Since DO-254 was released ten years ago, the knowledge of software hardware development processes, techniques, and strategies for safety-critical hardware has vastly changed and in some cases improved.  However, there is a large gap between understanding the real intent of DO-254 certification and the minimalist words in the Book. Just as commercial hardware development techniques have advanced, so has the world of aviation hardware development and certification. This Intermediate DO-254 training will provide important knowledge for attendees to rise to, understand, and apply those advancements and new hardware certification requirements for FAA, EASA and worldwide certification agencies.  This Intermediate DO-254 training is intended for persons with basic familiarity of DO-254, DO-178, or safety-critical standards. If no prior training, just request AFuzion’s training papers to read in advance – freely provided to attending students.  The developer/teacher is the principal founder of two of the world’s largest avionics consulting companies and the principal author of several of the world’s most popular publications on DO-254: Vance Hilderman has taught over 11,000 avionics engineers and managers worldwide, including FAA and EASA officials, and engineers from 95 of the world’s largest 100 aviation companies: more than all the competitor’s current trainers in the world, combined.

AFuzion’s training has been provided to over 17,500 aviation engineers from 1,000 companies in 30 countries; more than all other trainers in the world combined. Brief summary below; contact us for more free information.

 

KEY FEATURES:

  • Quick refresher on basic DO-254 and “how” DO-254 is applied to advanced avionics
  • Understanding CAST-27 and AC 20-152 and related EASA certification requirements
  • Understanding actual hardware DO-254 requirements with actual case study
  • Advanced analysis, element analysis, and structural coverage for hardware logic
  • Actual hardware PHAC review checklist walkthrough
  • Actual hardware HWPA (“quality assurance”) review checklist walkthrough
  • Representative SOI audits for Hardware – what are they for #1, 2, 3, and 4
  • Hardware Requirements Validation – what is involved
  • Applying DO-254 to Military AND Commercial usage; differences between EASA & FAA
  • Understanding advanced DO-254 mistakes and best practices to avoid them element analysis/coverage
  • Controlling engineering cost/risks with DO-254 Requirements, Design, and Logic
  • Understanding and applying AC 20-152, CAST-27, and EASA-CM-SWCEH-001 for avionics hardware development per ED-80 and DO-254

WHO:  Attendees may include engineers, managers, quality assurance or certification personnel with previous knowledge, training, or experience in DO-254.

 For More Info & Registration: Click here for DO-254 Seminar Info

==========================================================================

Formal DO-178C Advanced Avionics Software Development & Certification Training

Date: September 13-14, 2018

Location: Technological Park of São José dos Campos, SP – Brazil

Details:

DO-178C (ED-12CC) is arguably the world’s most difficult software “standard” and many millions of lives rely on it yearly. But software development has rapidly evolved along with aircraft design:  many new technologies must be considered, and certified: C++, Model-Based Development, Formal Methods, non-CPU based logic, and advanced tools. New techniques for specifying avionics requirements and design must also be understood.  But what are detailed and derived DO-178C requirements?  How can C++ and OOT be safely used and certified per DO-332?   What are DO-178C Model-Based Development best practices in applying DO-331?  What are the answers to applying DO-178C’s Parameter Data Items?  What were the DO-178B weaknesses and how is DO-178C really different from DO-178B?  How can DO-178C cost and schedule be reduced by 20-30%?

This advanced DO-178C training is intended for persons with basic familiarity of DO-178 or safety-critical standards. If no prior training, just request AFuzion’s training papers to read in advance – freely provided to attending students.  The developer/teacher is the principal founder of two of the world’s largest avionics consulting companies and the principal author of the world’s most popular publications on DO-178: Vance Hilderman has taught over 11,000 avionics engineers and managers worldwide, including FAA and EASA officials, and engineers from 95 of the world’s largest 100 aviation companies: more than all the competitor’s current trainers in the world, combined.

AFuzion’s training has been provided to over 17,500 aviation engineers from 1,000 companies in 30 countries; more than all other trainers in the world combined. Brief summary below; contact us for more free information.

 KEY FEATURES:

  • Quick refresher on basic DO-178C and “how” DO-178C is applied to advanced avionics
  • Grasp key differences between DO-178B and DO-178C for more advanced users
  • Advanced Safety, Derived Requirements, and Detailed DO-178C Requirements
  • Understanding advanced DO-178C mistakes and best practices to avoid them including model based development, OOT, and C++
  • Controlling engineering cost/risks with DO-178C Requirements, Design, and Code
  • Understanding & applying DO-178C’s Supplements for:
    –     DO-330/ED-215 Software Tool Qualification
    –     DO-331/ED-216 Model-Based Development and Verification
    –     DO-332/ED-217 Object-Oriented Technology
    –     DO-333/ED-218 Formal Methods Supplement
  • Who:  Attendees may include engineers, managers, quality assurance or certification personnel with previous knowledge, training, or experience in DO-178.

For More Info & Registration:  Click Here for DO-178C Seminar Info

Object Oriented Technology, Safety Critical, and DO-332: Achieving Success in Software

17 Jul

If you’re involved in modern software development, then you care about OOT, or “Object Oriented Technology”.  If your software is for high-reliability or safety-critical applications, then you really care about OOT, especially “safe” OOT.  Why? Simple:  systems are becoming more complex, software is doing more of that complexity management, and schedules are tightening; while there’s no single magic bullet, OOT provides many answers.  And don’t you wish you had a single book that explained OOT, provided a tutorial, had decent examples, and emphasized the safety critical aspects?  Impossible for a single book to provide such?  We get this question often during AFuzion’s various safety-critical development training courses.  Our trainers have learned to provide a consistent answer: understand “DO-332”, the aviation community’s guideline for safety-critical OOT and you’ll have many of the answers.  Here is a brief synopsis below, and the full 12-page technical whitepaper is available here for a free download: Click here for AFuzion’s Free 12-Page Technical OOT Whitepaper

DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, is a 150-page guideline governing OOT usage in airborne and ground-based aviation software. However, since true OOT is relatively new to aviation software, (though Ada ’95 has been around since … 1995), the authors of DO-332 faced a large hurdle: how to provide meaningful guidelines to persons generally unfamiliar with object oriented software? The answer was skillfully handled within DO-332 by blending practical “guidelines” with an introduction to OOT which laid a common foundation for OOT terminology, application and certifiability.
There are many ways of approaching software development; hundreds of books are in print with many seemingly preaching their own “methodology”. But as all the many colors in a peacock stem from basic Red-Green-Blue, software development at its most (overly) simplified vantage has two “primary colors”: functional structured design and object-oriented design. Unlike the peacock, with software these “colors” do not blend well; many software design elements are considered to be either “functional” or “object oriented”. Traditional functional software is designed by considering then structuring each sequence of computer actions one at a time. Conversely, object oriented software is designed by first articulating software objects and actions to be performed on those objects, then integrating such objects/actions into meaningful groups and events. Yes, functional design may have some objects. Yes, object oriented design will use some sequential structural behaviors. But as a few drops of oil can float on water, that oil and water are hardly integrated; similarly functional and object oriented design are two distinct approaches which in their pure forms do not integrate easily with each other.

Prior to the publication of DO-332, safety-critical software developers had few rules for applying OOT. Programming standards such as MISRA C++ were available and well; those were used and should still be applied along with a commercial static analysis tool to sanitize and improve C++ source code. However, clear guidance for safety-critical OOT design and verification was lacking; DO-332 attempts to fill that void. In functional software design, the control flow is preordained by the developer thus the sequence of decisions (“control flow” in DO-178C) is considered along with the input and output data function-by-function (“data flow” in DO-178C). A typical structured sequence is depicted below:

In object-oriented software design, the individual data flow and control flow aspects are encapsulated via objects as depicted in this OOT class diagram; note the low level data/control flow elements are less visible than in the structured diagram depicted previously: (see the full diagram in AFuzion’s OOT whitepaper available here: Free Download AFuzion’s DO-332 OOT Whitepaper

Safety-critical domains including aviation are risk-averse; new technologies are considered suspect until their safety is proven. In safety-critical software, determinism and verifiability are paramount. For many years traditionalists held that functional software development was more deterministic than OOT: structured software’s execution sequencing was easily determined and repeatable. And at the unit level (software functions and collections of functions within a file), functional structured software was more readily verified: source code sections could be traced directly to associated software low-level requirements (LLR’s) and tested sequence by sequence. Thus functional software design readily enabled determinism and verifiability, while doing so reliably for decades. With such a successful track record of reliability, why would anyone desire OOT with its radical paradigm shift? Simple: the very essence of evolution …

According to Darwinism, evolution occurs in nature when a genetic change is seen to provide advantages for survival. Similarly for technology, evolution occurs when a change provides economic advantage, which is commercial survival. The software evolution from functional design to OOT occurred for the simple reason that OOT increasingly embodied two economic advantages over functional design: 1) greater ability to manage increasing software complexity, and 2) greater reusability. The seeds of aviation software evolution thus sprouted.

To understand the need for OOT is to understand the need for DO-332: aviation software, like all software, was (and still is today) growing dramatically in size, complexity, and thus cost. Enhanced safety meant increased software functionality which meant increased software size and complexity. Functional structured software is fine, even advantageous, when functionality is simple. Computing power increased exponentially according to Moore’s law allowing aviation developers to harness that increased capability.
OOT Introduction.
In the iron age of computing (fifty to twenty years ago), software was written manually by conceiving the sequential instruction execution necessary to accomplish an objective. When close hardware support was needed, assembly language was favored for more direct CPU-level control; otherwise source languages such as FORTRAN, Ada, or C were typically used for scientific programming. Aviation software grew exponentially in the 70’s and 80’s, meaning Ada and C predominated as the language of choice. Improving both reusability and complexity management was increasingly important so smart developers deployed a variety of techniques toward these goals: encapsulation, hardware abstraction, wrappers, and building libraries of software components with generic and robust interfaces. While these techniques improved reusability and complexity management, the commercial consumer and financial sectors went much further: they rethought the entire premise of programming via writing sequential instructions and instead adopted object oriented (OO) programming via a variety of languages designed especially for OO support. The safety-critical world slowly followed though OO posed challenges to verification, and thus certification. To understand why OO had such challenges, it’s necessary to first understand OO.

Instead of merely conceiving and writing (“coding”) sequential instructions for a computer program, OO developers think in terms of Objects. An object contains encapsulated data and procedures which are combined together and thus represent an entity. An object is a data structure that contains data. Instructions (“code”) are implemented within procedures which are called “methods”. The object has interfaces which describe how it interacts within the program. Instead of thinking in terms of individual sequential instructions, OO developers perform programming at a higher level by defining objects and interactions which consist of groups of instructions instead of single sequential instructions. An object’s methods can access, and possibly update, data within the object. Objects have many forms as shown here (see AFuzion’s whitepaper for actual figures).

Objects then can take many different forms, but in each of these forms an object maintains the following attributes:
 Is an abstraction of a real-world concept or thing
 Has a clear boundary
 Has a unique identity
 Knows things about itself
 May perform actions on itself
 May interact with other objects

Like people, professions, and even aircraft, objects can vary dramatically in their functionality, ability, and complexity. At their most simplistic, there are three basic types of objects as depicted below:

As can be seen in AFuzion’s whitepaper on OOT, objects themselves are capable and interesting. But by themselves they are not that useful. Consider an aircraft engine: by itself it too is capable and interesting. However the engine becomes powerful and useful when combined with an aircraft structure, wings, and control systems. Similarly, an object becomes powerful and useful when used within the context of Object Oriented Programming (OOP). The basic concepts of OOP are the software design capabilities incorporated within the programming language, typically C++ for aviation and many of today’s safety-critical systems. These aspects are summarized in the figure below (download AFuzion’s whitepaper for the complete details).

For information on advanced DO-178C training and  software development for safety-critical applications, click here: http://afuzion.com/training/avionics-software-advanced-do-178c-training-class/