Eight specialisms. One standard of assurance.
High-integrity engineering applied across the full lifecycle, from TRL 1 concept research through design, qualification, trials and release into service to disposal. Every specialism is delivered to the standards your duty holder, independent safety auditor and prime will expect to see.
Engineering Leadership
Full-lifecycle technical leadership and management, bid to disposal — IDR, CDR, TRR, MRR and RTS.
On a programme
We take the technical lead from bid to disposal: producing the engineering and management plan, owning the work breakdown and basis of estimate, preparing and chairing the design reviews, and holding the balance between schedule, cost and assurance. Our engineers have held Safety Design Authority, Chief Systems Engineer, Systems Architect and Head of Engineering Integrity posts on multi-billion-pound programmes.
We also set up the organisational engineering process itself — the certification route, the safety and environmental management system, the review gates — and present the result to DE&S delivery teams, the MAA, DOSG, Dstl and Front Line Commands.
Standards & methods
- CADMID
- ISO/IEC/IEEE 15288
- MIL-STD-499A
- SAE ARP 4754
- JSP 553
- MOD ASEMS / POEMS
- SEMP / SEMS
- ISO 9001 / 14001
- Def Stan 00-56
- IDR · PDR · CDR
- TRR · MRR
- RTS / RTSA
Typical deliverables
- Engineering and Safety Management Plans, roadmap and WBS
- Basis of estimate for engineering and safety activities
- Design review packs and close-out of actions
- Technical and safety risk registers
- Release-to-Service and certification evidence
- Organisational engineering process and design certification process
Systems Engineering
Requirements and traceability, interface control, architecture, design, verification and validation.
On a programme
We turn a user need into a system that can be defined, traced, tested and defended: the system definition, design and functional descriptions, the system boundary and its interfaces with other systems, operators, maintainers and the surrounding environment. Modular functional and physical architectures with redundancy and diversity keep the sub-systems honest with each other, and interface control documents govern supplier responsibilities for function, performance, space, weight, safety, security and maintenance.
Requirements run from use cases and concept of operations down to low-level design specifications, with Measures of Performance and a Verification Cross Reference Matrix giving full source-to-verification traceability. Configuration and change control link requirements to hazard management, design changes and FRACAS/DRACAS.
Standards & methods
- ISO/IEC/IEEE 15288
- ISO/IEC/IEEE 29148
- SAE ARP 4754
- MIL-STD-499A
- INCOSE SE Handbook
- Def Stan 00-35
- Def Stan 59-411
- DOORS
- Rhapsody
- MATLAB / Simulink
- MBSE / SysML
- Visio · CAD
- VCRM
- Sequential environmental qualification
- HALT / HASS
- FAT · arena and live trials
Typical deliverables
- System definition, design and functional descriptions
- System boundary definitions and Interface Control Documents
- Modular functional and physical architectures
- User and System Requirements Documents with Measures of Performance
- Requirements traceability and Verification Cross Reference Matrices
- Trade studies, modelling and experimental analysis
- V&V plans, test procedures and integration test evidence
Systems Safety
Analysis, assessment, modelling, design for safety, compliance, ALARP justifications, safety assurance cases, risk assessment, safety planning and SEMS.
On a programme
We build the safety argument alongside the design rather than after it. Hazard identification, analysis and modelling feed design decisions — design for safety — across system architectures, electrical, electronic and programmable systems, software and firmware, mechanical, hydraulic and electro-hydraulic systems, ordnance and the human–machine interface. Derived safety requirements are linked to hazard mitigations and to their verification, so there is an auditable line from hazard to design feature to test.
Whether the duty holder needs an ALARP justification for a modification, an independent safety assessment, or a full safety case for a new platform, the output is written to stand up to scrutiny — and we chair the safety working groups and project safety committees that sentence it.
Standards & methods
- Def Stan 00-55
- Def Stan 00-56
- Def Stan 00-58
- Def Stan 00-972
- Def Stan 07-85
- JSP 375
- JSP 430
- JSP 454
- JSP 518
- JSP 520
- JSP 538
- JSP 550
- JSP 318B
- MIL-STD-882 & DIDs
- MOD ASEMS / POEMS
- MAA RA 3130 / 3132
- CAP 670
- MMATM
- ED-153 · ED-109A
- ARP 4761
- DO-178 · DO-254
- IEC 61508
- IEC 61511
- IEC 61513
- ISO 26262
- ISO 13849
- BS EN 50126 / 50128 / 50129
- BS EN 31010
- Yellow Book · ROGS · RM3
- NUREG-0492
- HSWA 1974
- R2P2 / ALARP
- Tolerability of Risk (HSE)
- COSHH EH40 / EH75
- Lees Loss Prevention
- HAZID · HAZOP · SWIFT
- PHA · FHA
- FTA · ETA
- CCA · ZHA
- OSHA · OHHA
- FMECA · FMEDA
- Markov · RBD · PTI
- SIL · DAL · ASIL assessment
- GSN · CAE
- Cost-benefit analysis
Typical deliverables
- Safety Management Plans and SEMS
- Hazard logs — Cassandra, DOORS or bespoke
- Derivation of safety requirements and their V&V activities
- PHA, SHA and SSHA; functional, physical and common-cause analysis
- Safety case reports (GSN / CAE), including electronic safety cases
- ALARP and R2P2 justifications
- SIL, ASIL and DAL assessments and compliance matrices
- Independent safety assessment and advice
- Trials safety cases and live-firing support
- Chairing Safety Working Groups and PSECs
Dependability & Quality
Reliability, availability, maintainability and security; process, product and supplier quality across the lifecycle.
On a programme
Dependability engineering — RAMS³: reliability, availability, maintainability, safety, security and survivability — tells the customer whether the platform will be available when it is needed, what it will cost to keep it so, and how the six properties trade against each other. Failure data, reliability block diagrams and proof-test intervals feed the same requirements set and hazard log as the safety work.
Quality engineering makes sure the process, the product and the supply chain deliver what the contract says: audits, non-conformance and concession management, supplier development, and a complete evidence pack when the acceptance board sits.
Standards & methods
- Def Stan 00-40
- Def Stan 00-41
- Def Stan 00-42
- BS 5760
- BS EN 50126
- PAS 55
- ISO 9001 / 14001
- Def Stan 00-35
- Def Stan 59-411
- MIL-HDBK-217
- NPRD (RIAC)
- Incident databases
- RBD
- FMECA · FMEDA
- Weibull · Markov
- Proof-test intervals
- FRACAS / DRACAS
- Life-cycle cost
Typical deliverables
- Dependability case and R&M case
- Reliability block diagrams and availability models
- FMECA, FMEDA and maintainability analysis
- Environmental and EMC qualification planning
- Quality plan and process audits
- Supplier audit and development reports
- NCR and concession management
Research & Development
TRL 1 to 9 — Integrated Full Electric Propulsion, power source and energy storage.
On a programme
We take a concept from horizon scan and paper study through demonstrator to qualified equipment, with the technology-readiness evidence at each gate. ADL currently leads Phase 1 of a government propulsion technology programme — Integrated Full Electric Propulsion and Energy Storage for the Submarine Delivery Agency and DE&S — from horizon scan and technology matrix through trade scoring on safety, reliability, availability, maintainability, survivability and performance, towards design and demonstration.
Current themes: IFEP and energy storage; fuel cells, lithium and non-lithium batteries, supercapacitors, battery management and charging; defence aeronautical data infrastructure modernisation with enhanced security, safety and availability; and control and instrumentation safety support to the Office for Nuclear Regulation. ADL is a proven Futures Lab lead organisation, collaborating with academia and manufacturing partners.
Standards & methods
- TRL 1–9
- MRL · SRL
- Horizon scan & technology matrix
- Trade studies & scoring
- UL 1642
- UL 2580
- UN 38.3
- IEC 62133
- MIL-STD-882
- UK Weapons Range Safety Regulations
- US Eastern & Western Range Safety Regulations
- Def Stan 07-85
Typical deliverables
- Concept of Use (CONUSE) and Concept of Operations (CONOPS)
- Horizon scan, technology matrix and scoring
- Derived requirements
- Initial design and detailed design
- Technology test and demonstration; full-scale demonstration
- Certification and manufacturing readiness
- Defence Innovation and Futures Lab bids and delivery
Artificial Intelligence
AI and artificial neural networks for platform health and usage monitoring and hazard detection.
On a programme
We bring specialist subject-matter expertise in AI modelling and in AI network architecture and infrastructure design. On the modelling side that means framing the problem and the data — pipelines, labelling, provenance and governance — then selecting, training and validating models (artificial neural networks and other machine-learning methods) against measurable performance targets, with explainability and drift monitoring built in.
On the infrastructure side it means designing the compute, storage and network the models run on: cloud or on-premise clusters, GPU and accelerator selection, data flows and APIs, and edge deployment on the platform itself, with the security and availability a defence system demands. Our AI heritage goes back to early neural-network aircraft health monitoring and hazard annunciation, and we treat any non-deterministic function as something to be bounded, monitored and accepted inside the platform safety case.
Standards & methods
- Def Stan 00-56
- IEC 61508
- DO-178
- ED-153
- ISO/IEC 42001
- ANN · ML
- Data pipeline & governance
- Model validation & drift monitoring
- MLOps
- Edge deployment
Typical deliverables
- AI concept, use case and data strategy
- AI network architecture and infrastructure design — compute, storage, network, edge
- Model development, training and validation reports
- HUMS / AHMS and hazard-annunciation concept and architecture
- Assurance and bounding argument for ML in safety-related systems
- Integration with the platform safety case
Networks & Cyber
Enterprise and cloud networks, API and data integration, cyber security and virtual machines.
On a programme
We design and secure the networks that programmes and platforms depend on — from national safety-critical data networks such as aeronautical data and aerodrome communication, navigation and surveillance infrastructure, to enterprise, cloud and virtualised environments. Data integrity assurance covers latency, corruption and unauthorised access, assessed through logical modelling, timing breakdown analysis and architectural assessment.
On the platform we work with the aerospace, land, rail and ship data buses that carry safety-related traffic. Cyber Essentials Plus certified ourselves, we help suppliers meet Defence Cyber Protection Partnership and JOSCAR expectations.
Standards & methods
- Def Stan 05-138
- Cyber Essentials Plus
- ISO/IEC 27001
- IEC 62443
- JSP 440
- NIST CSF
- MOD Secure by Design
- ED-153 · ED-109A
- CAP 670
- BS EN 60950
- ARINC 429 · 629
- MIL-STD-1553
- CAN · MILCAN
- Time-Triggered Ethernet
- SPI · RS-232
Typical deliverables
- Network architecture and segmentation design
- Data integrity assurance assessments
- API and data integration design
- Cyber risk assessment and treatment plan
- Cyber Essentials readiness and evidence packs
- Virtualisation and cloud environment design
Materials Fire Testing
Ship and submarine sample testing against defence specifications, with exclusive access to an IMO/UKAS-accredited test facility.
Send us the sample; we return the test report your naval authority or prime will accept.
Ask about fire testingWhat we test
- Cables, insulation and coatings
- Furnishings, panels and composites
- Flame spread, smoke and toxicity
- Heat release and ignitability
Specifications
- IMO FTP Code
- Defence specifications
- BS EN ISO 5659-2
- IEC 60332
- UKAS accredited
Need a specific mix? Talk to us.
Most programmes need three or four of these at once. Tell us the platform and the gate you are heading for.