I’m an eVTOL vehicle manufacturer. Is S1000D for us?

If, like me, you’ve been following the progress towards certification of Electric Vertical Take-Off and Landing (eVTOL) air vehicles, you’ll know that things are moving at pace.

This means that many organisations in the eVTOL industry are now reaching the stage where they need tools and processes  to create and manage the technical documentation for these innovative vehicles.

Whilst it’s not mandated, there is a strong argument for the adoption of the S1000D standard for eVTOL tech docs. However, if you have ever worked on an S1000D project you will know that there are definitely pros and cons to adhering to the S1000D specification.

With this in mind, if you are in the eVTOL space and thinking of heading down the S1000D route here is a very brief summary of what the S1000D specification is and answers to some of the common questions we are asked about S1000D and eVTOL projects.

S1000D is the internationally recognised specification within aerospace and defence for producing technical publications.

It ensures that manufacturers of all the systems, components and equipment that go into a platform (in this instance an eVTOL vehicle) create and deliver their product information in the same format. There are numerous other technical advantages of the S1000D specification, but for now, a ‘common format’ across the supply chain is what we’ll focus on.

S1000D is written in Extensible Markup Language (XML).

XML is a language and file format for storing, transmitting, and reconstructing arbitrary data. In simple terms, it’s a way in which we can write, manage and exchange all of the user manual data in a completely neutral – but vitally, structured – format, which is not proprietary to any one software vendor.

Yes and No.

XML is an open format, so to create S1000D compliant data, you must add an S1000D schema – a structured set of rules – on top of the XML.

Typically, an off the shelf XML editor won’t have the S1000D schema built into it, but in theory, most XML editors could handle S1000D and enable validation against the schema if you configured it to do so.

The problem of course with generic tools, is that you may only use 50% of the capabilities of those tools, meaning the interface is cluttered with menus and buttons you don’t want or need, adding to the learning curve and complexity.

Not all S1000D solutions are created equal.

There are a handful of tools out there that have S1000D at their core. Some good, some bad. I can almost guarantee one thing though; assuming you don’t have a background in S1000D, most will be daunting to the newcomer. And likely be dated in terms of the User Interface (UI).

And costly.

And difficult to set up and configure.

And the list goes on…

The S1000D specification is complicated (that’s one of the downsides) and historically, the tools to create and manage S1000D do little to remove the complexity for the system administrator or end users of the tools.

That’s why we created Xignal S1000D – but I won’t digress into that here. You can read more about the history of Xignal S1000D here or contact us for a demo and see for yourself.

The main reason I believe all companies involved in the eVTOL arena should seriously look at adopting S1000D, is for the very reason S1000D exists at all.

It’s the huge benefit of that uniform, vendor neutral format, where data can be exchanged between companies in a specification designed exactly for this type of data.  It also means you can harness the power of data reuse as eVTOL platforms mature, but that’s for another article.

It’s also about future proofing yourself.

If not now, it’s highly likely you’re going to have a big conversion programme on your hands somewhere down the road when that juicy contract you’re looking to win requires S1000D tech pubs (because the likelihood is that they will!).

The beginning of the project, or journey towards certification of a new vehicle, is literally the perfect time to make the decision to start on the right foot with S1000D.

And it really needn’t be daunting or expensive. (Contact us for a Xignal S1000D demo to see for yourself).

A good question. And this is one which has already got the attention of industry.

For example, there is currently no logical product breakdown structure within S1000D to support information on things such as Electrical Propulsion Units (EPUs), High voltage DC batteries for electrical storage, or actuation systems where the electrical motors act as the primary propulsion system for the craft.

The good news is that there is currently work taking place to adapt and enhance the S1000D technical publications specification to support eVTOL vehicles.

This work includes updates to the Standard Numbering System (essentially a standardised product breakdown tree) within the specification to enable the eVTOL industry to take full advantage of S1000D.

This is all being proposed to the S1000D steering committee via change proposals as we speak. And while not guaranteed, it’s very likely in my opinion to be taken seriously with the proposed changes finding their way into the next release. eVTOL, is after all, (arguably) the future and it would be somewhat disingenuous to ignore the needs of the evolving aerospace industry.

If you’re considering how you produce your technical publications to meet your safety, airworthiness, or regulatory requirements – or just trying to find a logical way to produce your user docs – I’d highly recommend looking at S1000D.

It’s mature, well supported, non-proprietary and gives complete flexibility of your end-user output format along with a host of other benefits.

But if you’re unsure if it’s the right approach for your project or don’t know where to start, get in touch with me via email  and we can chat through the pros and cons. I’ve worked on countless S1000D projects over the years so can share some insight into the best way to get started with your project and hopefully give you a bit of enlightenment. Or at least a friendly S1000D steer if nothing else.

All the best for now.
Jake