They used to... Maybe even when this was published in 2014.
1,047 karma · joined November 21, 2014
http://kje.ca (email: ken@) http://linkedin.com/in/kennethjamesedwards
[ my public key: https://keybase.io/kejaed; my proof: https://keybase.io/kejaed/sigs/hitw0c0Sng-l_SdqQlTydZor7J1Ff1rQcRwZ3jtx3K0 ]
They used to... Maybe even when this was published in 2014.
I got tired of finding documents with a figure we needed somewhere else and hunting for 15 minutes for the source material.
We number the figures PRJ-FIG_0001 and have the source files in a top level shared folder (or svn/git). Note it’s important to have the figure id in the figure itself as well as the file name so when it’s imported into a doc the ID is embedded in the figure itself.
One nice feature of this markup language is creating diagrams programmatically. We wrote a small python tool that will take a State Transition Table (States cross Events) and create the diagram. I have found it helpful to start from the table to ensure States and Events are well defined and all options are considered, but once that is done the diagram is also quite useful for discussion.
Things that we have found helpful are the MediaWiki plugin and the Word plugin.
We’ve also started adding unique identifiers to all diagrams across our large development program, and keeping all diagrams in one central spot. That alone has been almost as useful as PlantUML.
I think this applies to all disciplines “under” systems engineering too, the thing is with software there are often a lot more chances for things to go sideways compared to EE or mech in development.
The sooner you get the smart people in each discipline (Software or otherwise) to the table the better off everyone will be. This is why in systems engineering processes like ARP4754 you’ll see the word “preliminary” a lot. Preliminary architecture can be developed along with the system requirements as a basis for discussion with those performing the safety analysis and those implementing the software and hardware items. Having a software architect at the table, someone who can reason about the software architecture and its impact on the systems as a whole and the safety case can only help.
Discussing topics like Design Assurance Level and failure condition classification(major vs catastrophic), Single Event Upsets (bit flips), safety assessments in a really clear and well written way.
For example, I worked on a program where we certified the glass cockpit upgrade for the US Navy trainer, T-6A to T-6B with Transport Canada, the aircraft with the new avionics was certified by the FAA, and the whole system was then accepted by the US Navy. Satisfying all 3 stakeholders at the same time often proved difficult.
I’ve also considered starting a community makerspace in the west end of town, a coop or some sort of publicly funded model. This comment section is a good reminder that we had better have a solid operations plan in place for it to be a success.
MMIST is a provider of Precision Aerial Delivery products and services including the Sherpa family of GPS guided parafoils and the self-launch capable SnowGoose unmanned aerial vehicle (UAV), our SkyLink Android-based parachutist navigation aid, and our growing space recovery business.
My team is currently looking to hire software developers both for Android and our various embedded platforms. We are looking for people to join us on-site in the west end of Ottawa.
Embedded https://www.indeed.ca/m/viewjob?jk=32e66f5f60ce2342&from=com...
Android https://www.indeed.ca/m/viewjob?jk=09ed3ee187c4ddbb&from=com...
As the article says, the function of MCAS changed and its operational envelope was greatly expanded. What if, internally at least, the new system was referred to as MCAS2?
This is somewhere that things can get political, as was exactly the case with the Max, where they did not want anything to be considered a change to the aircraft type, let alone knowing the MCAS system existed in two majorly differing versions.
Especially if as the article says a failure of the AOA sensor on the system would be Hazardous (looks like it was Catastrophic when paired with MCAS in retrospect), that would have made the functional Design Assurance level for this system DAL B, which adds enough rigour not only in the software development process but so much before you even get to that in terms of Safety Assessments and ESPECIALLY change impact analyses when the function changes.
For sure there may have been pressure from management to keep MCAS out of the manual but it’s not really up to he regulatory agency to be experts on the aircraft design, if things are being hidden by the company then I’d consider this bordering on professional misconduct on the parts of the engineers overseeing this work.
I say this as a Professional Engineer working as an aerospace systems engineer.
Of course after spending so much time developing the formula sheet and working through the example problems (always the most important thing you can do), I think I looked at the sheet twice in 3 hours during the exam.
Also, Dr. Glen Takahara, this class and your instruction are one of my fondest memories at Queen’s!