Search Results

Day by day, airports adopt more IoT devices. However, airports are not exempt from possible failures due to malware’s proliferation that can abuse vulnerabilities. Computer criminals can access, corrupt, and extract information from individuals or companies. This paper explains the development of a propagation model, which started with a Delphi process. We discuss the preliminary implications for airports of the simulation model built from the Delphi recommendations.

SAE International’s two-day course, DO-326A and ED-202A: An Introduction to the New and Mandatory Aviation Cyber-Security Essentials, introduces attendees to industry best practices for real-world aviation cybersecurity risk assessment, development, assurance. ...SAE International’s two-day course, DO-326A and ED-202A: An Introduction to the New and Mandatory Aviation Cyber-Security Essentials, introduces attendees to industry best practices for real-world aviation cybersecurity risk assessment, development, assurance.

Argus, a global leader in automotive cybersecurity, has upgraded its stand-alone Fleet Protection backend platform and is now providing continuous live monitoring of both automotive and commercial aircraft fleets.

Cybersecurity attacks exploit vulnerabilities related to the increased complexity and connectivity of critical infrastructure systems. ...Network security is a core component of the overall cyber-security and defense-in-depth capability for distributed architectures. Protection mechanism for information, interface and system integrity, communication availability, and data confidentiality are required for design of safe and secure integrated embedded infrastructure.

The aircraft lifecycle involves thousands of transactions and an enormous amount of data being exchanged across the stakeholders in the aircraft ecosystem. This data pertains to various aircraft life cycle stages such as design, manufacturing, certification, operations, maintenance, and disposal of the aircraft. All participants in the aerospace ecosystem want to leverage the data to deliver insight and add value to their customers through existing and new services while protecting their own intellectual property. The exchange of data between stakeholders in the ecosystem is involved and growing exponentially. This necessitates the need for standards on data interoperability to support efficient maintenance, logistics, operations, and design improvements for both commercial and military aircraft ecosystems. A digital thread defines an approach and a system which connects the data flows and represents a holistic view of an asset data across its lifecycle.

This brief User Guide recaps the content of the AS6518B UCS Architectural Model. The purpose of the UCS Architecture Model is to provide the authoritative source for other models and products within the UCS Architecture as shown in the AS6512B UCS Architecture: Architecture Description.

Abstract With the recent advancement in technologies, researchers worldwide have a growing interest in unmanned aerial vehicles (UAVs). The last few years have been significant in terms of its global awareness, adoption, and applications across industries. In UAV-aided wireless networks, there are some limitations in terms of power consumption, data computation, data processing, endurance, and security. So, the idea of UAVs and Edge or Fog computing together deals with the limitations and provides intelligence at the network’s edge, which makes it more valuable to use in emergency applications. Fog computing distributes data in a decentralized way and blockchain also works on the principle of decentralization. Blockchain, as a decentralized database, uses cryptographic methods including hash functions and public key encryption to secure the user information. It is a prominent solution to secure the user’s information in blocks and maintain privacy.

This Technical Governance is part of the SAE UCS Architecture Library and is primarily concerned with the UCS Architecture Model (AS6518) starting at Revision A and its user extensions. Users of the Model may extend it in accordance with AS6513 to meet the needs of their UCS Products. UCS Products include software components, software configurations and systems that provide or consume UCS services. For further information, refer to AS6513 Revision A or later. Technical Governance is part of the UCS Architecture Framework. This framework governs the UCS views expressed as Packages and Diagrams in the UCS Architecture Model.

The basic requirements of AS9100A apply with the following clarifications. This document supplements the requirements of AS9100A for deliverable software. This supplement contains Quality System requirements for suppliers of products that contain deliverable embedded or loadable airborne, spaceborne or ground support software components that are part of an aircraft Type Design, weapon system, missile or spacecraft operational software and/or support software that is used in the development and maintenance of deliverable software. This includes the host operating system software including assemblers, compilers, linkers, loaders, editors, code generators, analyzers, ground simulators and trainers, flight test data reduction, etc., that directly support creation, test and maintenance of the deliverable software.

This document is the Architecture Description (AD) for the SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture Library Revision A or, simply, the UCS Architecture. The architecture is expressed by a library of SAE publications as referenced herein. The other publications in the UCS Architecture Library Revision A are: AS6513A, AS6518A, AS6522A, and AS6969A.

The federal government and industry have moved to concurrent acquisition and development processes using integrated process teams (IPTs). These processes are supported by timely, accurate, cross functional access to data within an integrated data environment (IDE) enabled by advances in information technology (IT). Since the advent of acquisition reform in 1994, Data Management (DM) practices have evolved from being directed by a prescriptive set of standards and procedures to use of the guidance in a principles-based standard -- ANSI/EIA 859.

GEIA Handbook 859 provides implementation guidance for ANSI/EIA 859, with discussions of applications of the standard's principles, tools, examples, and case studies. Handbook 859 is organized according to the lifecycle of data management and covers activities from the pre-RFP stage through records disposition.

This document describes a process for use by ADHP integrators of EEE parts and sub-assemblies (items) that have been targeted for other applications. This document does not describe specific tests to be conducted, sample sizes to be used, nor results to be obtained; instead, it describes a process to define and accomplish application-specific qualification; that provides confidence to both the ADHP integrators, and the integrators’ customers, that the item will performs its function(s) reliably in the ADHP application.

This document outlines a standard practice for conducting system safety. In some cases, these principles may be captured in other standards that apply to specific commodities such as commercial aircraft and automobiles. For example, those manufacturers that produce commercial aircraft should use SAE ARP4754 or SAE ARP4761 (see Section 2 below) to meet FAA or other regulatory agency system safety-related requirements. The system safety practice as defined herein provides a consistent means of evaluating identified risks. Mishap risk should be identified, evaluated, and mitigated to a level as low as reasonably practicable. The mishap risk should be accepted by the appropriate authority and comply with federal (and state, where applicable) laws and regulations, executive orders, treaties, and agreements. Program trade studies associated with mitigating mishap risk should consider total life cycle cost in any decision.

The difficulty in locating crash sites has prompted international efforts for alternatives to quickly recover flight data. This document describes the technical requirements and architectural options for the Timely Recovery of Flight Data (TRFD) in commercial aircraft. ICAO and individual Civil Aviation Authorities (CAAs) levy these requirements. The ICAO Standards and Recommended Practices (SARPs) and CAA regulations cover both aircraft-level and on-ground systems. This report also documents additional system-level requirements derived from the evaluation of ICAO, CAA, and relevant industry documents and potential TRFD system architectures. It describes two TRFD architectures in the context of a common architectural framework and identifies requirements. This report also discusses implementation recommendations from an airplane-level perspective.

Propulsion Fanjet Evolution - the Next Steps Composites Dry Drilling Composites Using Carbon Dioxide Cooling

Laser Detecting Systems Enhancing Survivability and Lethality on the Battlefield Designing With Plastics for Military Equipment Engine Air-Brakes Paving the Way to Quieter Aircraft Nett Warrior Enhancing Battlefield Connectivity and Communications XPONENTIAL 2018 - An AUVSI Experience Communications in Space: A Deep Subject First Air-Worthy Metal-Printed RF Filter Ready for Takeoff Validation of Automated Prediction of Blood Product Needs Algorithm Processing Continuous Non-Invasive Vital Signs Streams (ONPOINT4) Using a combination of non-invasive sensors, advanced algorithms, and instruments built for combat medics could reduce hemorrhaging and improve survival rates. Calculation of Weapon Platform Attitude and Cant Using Available Sensor Feedback Successful development of mobile weapon systems must incorporate operation on sloped terrain.

The researchers at the COE for Assured Autonomy in Contested Environments – all of which histories of innovation for Department of Defense problems of interest – will focus on the availability, integrity, and effective use of information by leveraging its diverse expertise in dynamics, mathematics, control theory, information theory, communications, and computer science.

Software needs security. That's a consequence of using software to control critical systems. It's difficult because software is inherently a complex artifact, even when the code just consists of a single sequential program in a single programming language, with well-defined inputs and outputs. Of course, actual software rarely if ever has such a simple structure. Security needs software. That's a consequence of the complexity just mentioned. No process can ensure security at scale unless it is automated by using software itself: programming languages, verification tools, software platforms.