Frequently Asked Questions (FAQs)
ALTEN Global Technologies has designed and developed a Class Beta 3 GPS-SBAS receiver that is compliant to FAA TSO-C145c. The GPS receiver is used in many GA (General Aviation) aircraft like Eclipse, Beechcraft, Cessna, Dornier, Pilatus etc.
ALTEN Global Technologies has also successfully participated in many customer programs that involve TSO-C195a, TSO-C157a, TSO-C154c, TSO-C113, TSO-C43c, TSO-C49b, TSO-C44c, TSO-C47a and TSO-C55a.
The Federal Aviation Administration (FAA) of the United States of America is a national authority that regulates all aspects of civil aviation within the US NAS (National Airspace System). It is responsible for safety in Civil Aviation in the USA. FAA is one of the two main agencies worldwide for the certification of aircraft and aircraft parts.
The European Aviation Safety Agency (EASA) is an agency of the European Union established in 2002 that is responsible to ensure a high and uniform level of safety in civil aviation, by the implementation of common safety rules and measures. The responsibilities of EASA include drafting of aviation safety legislation, airworthiness and type certification of aircraft and aircraft parts for aircraft operating in the EU. Certifications by FAA or EASA are accepted worldwide.
Yes, the FAA and EASA mutually recognize each other’s aircraft certification systems. The FAA and EASA have mutually signed an Agreement on cooperation in the regulation of Civil Aviation Safety. The FAA and EASA have jointly agreed that they should actively promote mutual rulemaking cooperation to maintain and further improve the harmonization of their rules within the European Union and the USA. There is reciprocal acceptance of the certifications of each authority.
The processes followed by both FAA and EASA for certifications are mostly similar. The TSO documents from each organization call out the same MOPS document released by Radio Technical Commission for Aeronautics (RTCA).
A Type Certificate (TC) is issued by the US National Aviation Authority (NAA) of the State of the Operator stating the airworthiness of a category of aircraft. It confirms that the aircraft is manufactured according to an approved design, and that the design ensures compliance with airworthiness requirements.
A Supplemental Type Certificate (STC) is a document issued by the Federal Aviation providing approval of a design change in the originally approved design on a specific aircraft type. It defines the change in the design and its impact on the existing design.
When a LRU is TSO approved by FAA and is to be installed on an aircraft, a STC is usually to be obtained as this is a change and the airworthiness of the aircraft type is to be established.
CEMILAC is the certification agency for all military aircraft/airborne systems, and aero engines. Total external certification is in practice for all military aircraft project. CEMILAC carries out a thorough evaluation of the design, utilizing such aids, simulation techniques, structural analysis, safety analysis, analogous studies and test evaluation. These analyses are carried out by the design and development agencies themselves or independently by CEMILAC. CEMILAC also verify upgrades of software and integration of indigenous systems. The process is completely different from FAA.
DGCA is like FAA in India. It stands for Directorate General of Civil Aviation. This agency is under Ministry of Civil Aviation and investigates aviation accidents and incidents. Both CEMILAC and DGCA are airworthiness regulatory agencies, but the method of regulation and nature of evaluation differs. The DGCA is a statutory body and hence has legal implications. The DGCA approves designers, manufacturers and gives complete responsibility to authorized signatories in design and manufacturing agencies. The requirements to be fulfilled are clearly laid down by DGCA. The DGCA practices these regulations and interacts with its foreign counterparts
No, our products are CEMILAC certified for use in military aircraft.
MIL1553 standards are used for LGEIU (Landing Gear Electronics Interface Unit) project for a defence customer. The project is part of the RLV (Reusable Launch Vehicle) Program.
DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with software used in certain airborne systems.
It was jointly developed by the safety-critical working group RTCA SC-167 of RTCA and WG-12 of EUROCAE. RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B.
ALTEN Global Technologies has worked on all the levels(A-E) of DO-178B/C
ALTEN Global Technologies has worked on all the levels(A-E) of DO-178B/C. Some examples are listed below
Data Acquisition Unit (DAU) and Configuration Module Unit (CMU: The DAU is a data conversion unit capable of processing data from engine and various aircraft sensors and outputs the data to displays. Configuration Module Unit is a microprocessor-based unit, which stores Aircraft Configuration Data (ACD) i.e., parameters related to different engine and aircraft configurations.
The Display Unit graphically represents various Aircraft and Engine Parameters. It receives the aircraft and engine parameter information through A429 bus (example, from the Data Acquisition Unit (DAU)) and converts it to the graphical representation of the engine and aircraft parameters like EOP, EOT, TOT, OAT, N1, N2, NR etc.
GPSB : The GPSB is a navigation sensor that can acquire and track GPS satellite signal and determines the position, velocity and time. It also performs Receiver Autonomous Integrity Monitoring (RAIM) of the navigation solution using the measurements from redundant GPS satellites. The GPS-SBAS receiver provides additional integrity by acquiring information from SBAS satellites that broadcast GPS health, integrity information and ionospheric corrections. The SBAS networks provide differential corrections.
The ARINC 429 data to CSDB Converter, which converts data from ARINC 429 format to CSDB format and RS-232 format as per the configuration mapper tables. BA-110 logs fault status information in its Non-volatile memory which can be later used for diagnostic purpose.
NexNav G2S+: The NexNav G2S+ Global Navigation Satellite Sensor Unit (GNSSU) is a satellite sensor that utilizes the signals coming from Global Positioning System (GPS) satellite constellation, GLObal NAvigation Satellite System (GLONASS) and Satellite-Based Augmentation System (SBAS). Wide Area Augmentation System (WAAS) is one example of SBAS.
The primary function of NexNav G2S+ GNSSU is to compute the position, velocity of an aircraft and the precise time (PVT). It also computes the integrity of the PVT from the SBAS signal, if available.
SELCAL: The CSD-714 Mark 4 SELCAL decoder is an airborne, rack mounted, five channel, 32 tone decoder designed in accordance with ARINC 714A. It is used to receive and decode SELCAL signals made up of four combinations of the 32 tone frequencies defined in ARINC 714A and RTCA/DO-93A. Its purpose is to recognize a SELCAL signal intended specifically for the aircraft in which it is installed.
Acronyms:
ARINC:
Aeronautical Radio, Incorporated.
CSDB:
Commercial Standard Digital Bus
DAL:
Design Assurance Level
EOP:
Engine Oil Pressure
EOT:
Engine Oil Temperature
GPSB:
GPS-SBAS sensor for Precision Approach
N1:
Engine Gas Producer Speed
N2:
Engine Power Turbine Speed
NR:
Rotor Speed
OAT:
Outside Air Temperature
RTCA:
Radio Technical Commission for Aeronautics
SBAS:
Satellite-based Augmentation System
SELCAL:
Selective Calling
TOT:
Turbine Outlet Temperature
Over several years, ALTEN Global Technologies has gained a vast experience of working on DO178B/C level A and Level B projects on various prestigious programs of Boeing 787 (Wing Ice Protection Systems), MRJ (Landing Gear Steering Controls), Gulfstream (Landing Gear Steering Controls), Embraer ((Landing Gear Steering Controls), Airbus programs (various subsystems).
Errors and Inconsistencies: DO-178C addressed DO-178B’s known errors and inconsistencies. For example, DO-178C has addressed the errata of DO-178B and has removed inconsistencies between the different tables of DO-178B Annex A. In removing an inconsistency regarding software standards for Level D software, DO-178B objective A-9 #1 addressing plans and standards was split into two DO-178C objectives, specifically:
Consistent Terminology: DO-178C addressed DO-178B’s issues with the use of specific terms such as “guidance”, “guidelines”, “purpose”, “goal”, “objective” and “activity” by expanding the Glossary and changing the text accordingly so that the use of those specific terms was consistent throughout the document.
Wording Improvements: DO-178C made wording improvements throughout the document. All such changes were made simply to make the document more precise; they were not meant to change the original intent of DO-178B.
Objectives and Activities: DO-178C reinforced the point that, in order to fully understand the recommendations, the full body of this document should be considered. For example, Annex A now includes references to each activity as well as to each objective; and Section 1.4, titled “How to Use This Document” reinforces the point that activities are a major part of the overall guidance.
Technology Supplements: DO-178C recognized that new software development methodologies may result in new issues. Rather than expanding text to account for all the current software development methodologies (and being revised yet again to account for future software development methodologies), DO-178C acknowledged that one or more technology supplements may be used in conjunction with DO-178C to modify the guidance for specific technologies or methodologies. Section 12’s addressing of tool qualification and alternative methods was heavily impacted since planned technology supplements more completely address such technologies. They include Model-Based Development, OOT, Formal Methods and Tools.
Coordinated System/Software Aspects: DO-178B updated Section 2, which provides system aspects relating to software development, to reflect current system practices.
DO-178B “Hidden” Objectives: DO-178C added the so-called “hidden objectives” to Annex A:
A means for detecting object code that is not directly traceable to the source code and a means to ensure its verification coverage are defined. (Table A-7 #9)
Assurance is obtained that software plans and standards are developed and reviewed for consistency. (Table A-9 #1)
DO-178B General Topics: DO-178C addressed a few general topics that resulted in changes to several sections of the document. The topics included a variety of subjects such as applicant’s oversight of suppliers, Parameter Data Items and traceability. In addressing these topics, additional objectives were added to Annex A:
Correctness, Completeness and Verification of Parameter Data Item Elements. (Table A-5 #8 and #9)
Parameter Data Item file to be loaded in target computer. (Table A-2 #7)
Added Trace Data as required Lifecycle Data to be provided and verified (Section 11.21, Table A-2 and Table A-6)
DO-178B Gaps and Clarifications: DO-178C addressed several specific issues that resulted in change to only one or two paragraphs. Each such change may have an impact upon the applicant as these changes either addressed clear gaps in DO-178B or clarified guidance that was subject to differing interpretations.
Examples of gaps addressed include:The “Modified Condition/Decision Coverage” definition changed. Masking MC/DC and Short Circuit, as well as DO-178B’s Unique-Cause MC/DC, are now allowed. (Glossary)
For Level A, added that “if a compiler, linker or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences.” (6.4.4.2.b)
Derived requirements should now be provided to the system processes, including the system safety assessment process (rather than just provided to the system safety assessment process) (5.1.1.b; 5.2.1.b)
Examples of clarifications include:Clarified that the structural coverage analysis of data and control coupling between code components should be achieved by assessing the requirements-based tests. (6.4.4.2.c)
Clarified that all tests added to achieve structural coverage are based on requirements. (6.4.4.2.d)
Clarified the types of code that may be classified as Deactivated Code. (6.4.4.3.d)
Software Design Assurance Level, SW Tools required, SW for ATE to be developed and maintained, Integration Support, Reusability of existing hardware/software tools
We use a heuristic method in many of the testing projects. The heuristic data is gathered over many years of execution of similar projects. Organization metrics are created from heuristic data and are updated annually. This data is used in estimating projects.
In addition, we use the following techniques in estimating new projects:
In addition to the V-model, ALTEN Global Technologies uses many other development life cycles. ALTEN Global Technologies has expertise in employing different lifecycle models to suit the needs of the Customer and the requirements of the program:
Accords has always highlighted the value of accurate documentation for certification purposes and irrespective of the lifecycle model selected, ALTEN Global Technologies ensures that documentation of high standards is generated.
ALTEN Global Technologies has participated in developing System Level Requirements for the following projects:
ALTEN Global Technologies has generated Software Requirements in all the full life cycle products designed and developed at ALTEN Global Technologies. These projects include the ones listed below and many other customer projects
ALTEN Global Technologies uses DOORS as well as the in-house developed tool ReMa (Requirements Manager) for managing Requirements. DOORS is widely used tool for maintaining requirements but is constrained by licensing costs. ALTEN Global Technologies developed its own tool, ReMa, as a cost-effective solution to manage requirements. ReMa has most features supported by DOORS and supports importing data from DOORS into its own database.
ReMa (Requirement Manager) is a software developed by ALTEN Global Technologies for managing requirements. It is a systematic and powerful tool which helps in organizing, tracing and managing requirements throughout the project life cycle. ReMa helps in achieving
- Shorter release cycles - Low cost - High quality - Conformance to customer requirements - Collaboration and communication among team members. ReMa is compatible with DOORS. ReMa has most features supported by DOORS and supports importing data from DOORS into its own database.
Yes, ReMa has undergone tool qualification for DO-178B projects.
ReMa is not available for purchase yet, but available as an In-house tool. ReMa can be used directly in customer projects or it can be used to reduce the purchase of number of licenses of industry wide accepted DOORS requirements management tool. REMA supports importing/export of its database from/to DOORS. Hence a bigger team can be managed with ReMa and a single license of DOORs.
No, we do not have web-based version of ReMa. Currently ReMa is available as a Client Server version
No, support is available as ReMa is not for purchase.
Some of the projects where ALTEN Global Technologies has developed System Architecture are listed below:
- a) Navigation Communication Radio Prototype
- b) L Band Transceiver Demo Project
- c) GPS-UAT Multilink Surveillance Systems for ADS-B applications
- d) Selective Calling Radio
- e) Multi Constellation GNSS Intellectual Property and System on Chip Design
- f) Integration of GPS Base band IP on customer SOC designs
- g) CDMA Receivers
- h) Satellite Ranging Receiver
- i) Aerospace GNSS Receivers
- j) FPGA DO-254 process Engineering Services
- k) IRNSS reference Receiver
- l) GNSS Simulator
- m) GNSS System on Chip
ALTEN Global Technologies has developed and contributed to Software Architecture in many projects. A few are listed below:
- a) Control & Display unit for Rotorcraft
- b) Early Warning Systems for Rotorcraft
- c) Airborne Transponder Software for General Aviation
- d) Data Acquisition Units for Rotorcraft
- e) Data loaders using 615A
- f) Base Software Architecture based on AUTOSAR
- g) Automotive Telematics Control Units
- h) Fleet Management Server Software Architecture
- i) Airport Baggage Handing Report Generation Software
- j) Network monitoring tool for Airport Networks
- k) Distributed database element Design for Airport Baggage databases
- l) Development of Generic Architectural Components
- m) Landing Gear, Steering Control Systems Software
Following are some of the programming languages used in the past projects:
Following are some of the activities performed in low level testing:
Following are the tools used for Unit testing:
SmartTester is a unit testing tool designed to automate the process of unit testing C code. It improves productivity and quality in software development and verification processes. SmartTester automates the creation of unit and component test harnesses, test stubs and test drivers. User must select the C module, which contains the unit that must be tested. Tool generates a test template in which user will have to add normal and robustness test cases for the unit under test (UUT). Test cases are executed, and detailed test and run-time coverage analysis reports are generated.
Comparison with Other tools:
| Feature | SmartTester | RTRT | Cantata | VectorCAST | LDRA |
|---|---|---|---|---|---|
|
Automation of Test Script Template Generation |
Generates test script template from the source and identifies the stubs. |
Generates test script template from source and identifies the stubs. |
Test environment is created. Variables and Stubs are automatically listed in the GUI. Test script file has to be exported from the GUI as the test manager is GUI based. |
Test environment is created. Variables and Stubs are automatically listed in the GUI. Test script file has to be exported from the GUI as the test manager is GUI based. |
Test environment is created. Variables and Stubs are automatically listed in the GUI. Test script file has to be exported from the GUI as the test manager is GUI based. |
|
Syntax highlighting |
Keyword/Syntax highlighting is present in the Test script editor |
Keyword/Syntax highlighting is present in the Test script editor |
No such feature as it is GUI based. |
No such feature as it is GUI based. |
No such feature as it is GUI based. |
|
Variable Type and Range Check |
No such feature. |
No such feature. |
Identifies the types and ranges of the variables/parameters tested. The input values can be added through the GUI. |
Identifies the types and ranges of the variables/parameters tested. The input values can be added through the GUI. |
Identifies the types and ranges of the variables/parameters tested. The input values can be added through the GUI. |
|
Host/Target Execution |
Supports Host and target execution |
Supports Host and target execution |
Supports Host and target execution |
Supports Host and target execution |
Supports Host and target execution |
|
Report Generation |
Generates a detailed Pass/Failed report for each test case. |
Generates a detailed Pass/Failed report for each test case. |
Test pass or fail is indicated in the GUI. The report can be exported. |
Test pass or fail is indicated in the GUI. The report can be exported. |
Test pass or fail is indicated in the GUI. The HTML format of the report can be exported. |
|
Static/Dynamic Analysis |
Performs both Static and Dynamic Analysis. Our CodeTrax is used to perform Static Analysis. |
Performs both Static and Dynamic Analysis. |
Performs both Static and Dynamic Analysis. |
Performs both Static and Dynamic Analysis. |
Performs both Static and Dynamic Analysis. |
|
Features of Static Analysis |
Static Analysis includes - Lines of Code, Comments, Cyclomatic Complexity, Halstead code complexity, McCabe code complexity, Data Dictionary, File level metrics, Function level metrics and Macro reference |
Static Analysis includes - Lines of Code, Comments, Cyclomatic Complexity. |
Static Analysis includes - Code Lines, Comments, McCabe, Myers, etc. |
Static Analysis includes Basis Path analysis and Cyclomatic Complexity. |
Static Analysis includes - Lexical Syntactical analysis of code, Programming standards verification, Complexity Analysis like Control Flow Knots, Cyclomatic complexity, Reachability, Looping Depth and Halstead's Metrics, Call Graphs, Bar Charts, Kiviat Diagram |
|
Features of Dynamic Analysis |
Dynamic Analysis includes - Memory Profiling, Performance Profiling, Code Coverage Analysis. |
Dynamic Analysis includes - Memory Profiling, Performance Profiling, Code Coverage Analysis. |
Dynamic Analysis includes only Code Coverage |
Dynamic Analysis includes only Code Coverage |
Dynamic Analysis includes - Code Coverage Level A B, Data Flow coverage. |
|
Coverage Report |
Code Coverage Analysis gives overall coverage results along with test by test coverage results, levels A B. |
Code Coverage Analysis gives overall coverage results along with test by test coverage results, levels A B. |
Code Coverage Analysis gives overall coverage results along with test by test coverage results, levels A B. |
Code Coverage Analysis gives overall coverage results along with test by test coverage results, levels A B. |
Code Coverage Analysis gives overall coverage results along with test by test coverage results, levels A B. It can be also customized to give object code coverage for the processor under consideration |
|
Stubs |
Allows stubbing |
Allows stubbing |
Allows stubbing and wrapper functions. |
Allows stubbing. |
Allows stubbing and wrapper functions. |
|
Import/Export Feature |
Test scripts from RTRT, Cantata (Version 3.4) can be imported /exported and executed in SmartTester. |
No such feature. |
Provides converter for converting scripts of RTRT to Cantata |
Supports migrating the test cases from tools RTRT, Cantata and LDRA |
No such feature. |
|
Types of Testing |
Can be used only for Unit Testing |
Can be used for Unit/Integration/System Testing. |
Can be used for Unit/Integration/System Testing. |
Can be used for Unit/Integration Testing. |
Can be used for Unit/Integration/System Testing. |
|
Languages supported |
Supports testing of C code |
Supports testing of source code in C, C++, ADA, Java |
Supports testing of source code in C, C++ and ADA |
Supports testing of source code in C and C++ |
Supports testing of source code in C, C++, ADA, Java |
|
Industries supported |
Supports Only Aerospace industry |
Supports Only Aerospace industry |
Supports Aerospace, Automotive, Railway, Medical and Nuclear industries |
Supports Avionics, Automotive, Railway, Medical industries |
Supports Avionics, Automotive, Railway, Medical industries |
No, SmartTester is not available for purchase. SmartTester is available as an In-house tool. SmartTester can be used directly in Customer projects or it can be used to reduce the purchase of number of licenses of industry wide accepted testing tools. SmartTester supports conversion of its test script into test script of Rational Test Real Time (RTRT). The Team generates test scripts on SmartTester and produces test results on RTRT by converting SmartTester test scripts into RTRT test scripts. Hence a bigger team can be managed with SmartTester and just one or two licenses of RTRT.
Yes, SmartTester has undergone tool qualification for DO-178B Level B projects.
No support is available as SmartTester is not for purchase.
- a) Unit Testing - It focuses on smallest unit of software design. In this, we test an individual unit or group of inter related units
- b) Integration Testing -
-
Integration testing has 2 types of approaches basically: - c) Black Box testing - It is used for validation. In this we ignore internal working mechanism and focuses on what is the output
- d) White Box testing - It is used for verification. In this we focus on internal mechanism i.e. how the output is achieved
- e) Grey Box testing - Grey-box testing is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects if any due to improper structure or improper usage of applications.
- f) System Testing - In this we just focus on required input and output without focusing on internal working. This include functional as well as nonfunctional testing
- g) HSIT (Hardware Software Integration Testing) - In this we test the entire system together as such with software being integrated with the hardware unit.
- h) Alpha Testing - This is a type of validation testing. It is a type of acceptance testing which is done before the product is released to customers. It is typically done by QA people.
- i) Acceptance / Beta Testing - The beta test is conducted at one or more customer sites by the end-user of the software. This version is released for the limited number of users for testing in real time environment
- j) Smoke Testing - This test is done to make sure that software under testing is ready or stable for further testing. It is called smoke test as testing initial pass is done to check if it did not catch the fire or smoked in the initial switch on or when it is deployed.
- k) Regression Testing - Every time new module is added leads to changes in program. This type of testing makes sure that whole component works properly even after adding components to the complete program.
- l) Stress Testing - Stress testing is used to test the stability & reliability of the system. In this we give unfavorable conditions to the system and check how they perform in those condition.
- a) Unit Testing - Calculation errors, Control flow errors, Compilation Errors, Logical errors
- b) Integration Testing - Interface errors between various modules of a software, algorithmic errors, run-time exceptions
- c) System and HSIT Testing - Functionality errors that does not meet the system/software requirements will be found out during this type of testing
- d) Alpha testing - The bugs that were not discovered through previous tests
- e) Beta Testing - This helps in finding the bugs in the customer's environment. Direct feedback from customers is a major advantage of Beta Testing
- f) Regression Testing - Defects that may be generated newly as a result of side-effects due to the changes done to a module are found during Regression testing.
- g) Stress Testing - This test mainly determines the system on its robustness and error handling under extremely heavy load conditions. Most prominent use of stress testing is to determine the limit, at which the system or software or hardware breaks.
Yes. We have developed single and multi-partitioned applications on ARINC 653 based Operating Systems. We have used VxWorks-653 for the development of Utility Management System (UMS) software for a fixed wing Aircraft. We have used OASYS-653 (Accord’s ARINC 653 Based operating system) Control Saturation Warning System (CSWS) and Control Display Unit (CDU) software development. These systems are flying in rotorcraft platforms in India and certified by CEMILAC (Center for Military Avionics and Certification). We have also worked with Integrity-178B for the development of Ethernet Based Data Loading Software compliant to ARINC 615A standards.
OASYS-653 is a real-time embedded operating system for Avionics Platforms. It is developed by ALTEN Global Technologies and is being used in avionics products which go through airborne certification. It supports ARINC 653-1 specifications. VxWorks or Integrity comes with the full fledged tool suite (compiler, debugger, os-profiler etc.,) OASYS-653 provides a library of the Operating System APIs
Yes. We have used OASYS in Control Saturation Warning System (CSWS) and Control Display Unit (CDU) Airborne Products.
Not as a standard purchase. ALTEN Global Technologies can port OASYS to any hardware platform as per the Customer’s requirement.
ALTEN Global Technologies can support the porting and verification of ARINC653 standards on any embedded platform.
The following main topics are additional to DO178B, which need to be taken care when transitioning to DO178C:
Tools used in the development, testing and building of Airborne SW needs qualification based on guidelines provided in DO-178B or DO-178C. Tools need qualification when they remove, reduce or automate processes in the life cycle with their output not being manually verified. If the output of such tools is manually verified, tool qualification may not be necessary. Tool qualification ensures that the output of the tools does not introduce errors into the process while saving time/cost.
SmartTester and RTRT are qualified in Unit Testing and CodeTrax is qualified in Code Rule Verification of C Coding Standards.
According to DO-178B, Software development tools that require qualification should adhere to the same development processes that are applicable to the SW being developed. The tools should be assigned the same DAL as the SW being developed. Tool Operational Requirements need to be generated and reviewed for completeness, correctness and accuracy. Compliance of the tool to the Tool Operational requirements should demonstrated.
Verification tools need to comply to the Tool Operational Requirements.
DO-178C provides Tool Qualification Levels based on the tool type and the DAL of the SW being certified. Based on the Tool Qualification Level, the qualification requirements are detailed in a separate order DO-330.
Airborne Early Warning System provides Audio and Visual warnings to the pilot to take immediate control/action when flight conditions exceed a predetermined limit. The Audio and Visual warning shall be provided well before helicopter enters into envelope of control saturation based on the algorithm for early detection of control saturation.
Yes. Airborne Early Warning System is built as per the system specification provided by HAL
We have done Safety Assessment and Analyses as per the ARP4761 guideline which includes Piece-Part FMEA (Failure Modes and Effect Analysis) to demonstrate the AC 25.1309 fail-safe concept, Reliability analysis (using MIL-HDBK-217F – military handbook) and FTA (Fault Tree Analysis) to comply with inbound Functional Hazard Analysis (FHA) requirements and Single Event Effects analysis (SEE) which is an emerging topic as per IEC 62396 and FAA documents
- a. Aerospace grade GNSS Receiver
- b. Airborne Transponders for General Aviation
- c. Control & Display unit for Rotorcraft
- d. Early Warning Systems for Rotorcraft
RTCA DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) was designed to fill gap for developmental assurance for complex electronic hardware, including programmable logic devices (PLDs) and application specific integrated circuits.
- a) Data Concentrator (Verification)
- b) Slat Flap Controller & Sensor (Design and Verification)
- c) Pilatus PC-24 (Design and Verification)
- d) DFCC Mark2 (Verification)
- e) Tool Qualification of HDL Designer 2012.1 - Design Checker
- f) Verification of MDL to HDL conversion for MATLAB Simulink generated VHDL files
- g) GPS-SBAS Receiver for precision Approach (NexNav Beta 1) (Design and Verification)
- h) GPS-SBAS Receiver for precision Approach (NexNav Beta 3) (Design and Verification)
- i) Optical Transceiver Bus (Design and Verification)
- j) ACSS ATDL (Verification & Validation)
- k) ACSS ATDL (Verification & Validation)
- l) Interior Lighting System (Design and Verification)ADS-B/UAT/Transponders NextGen ADS-B Compliance Appliance(Design and Verification)
- 1. Design Assurance Level
- 2. Scope of Work:
-
- Complete DO-254 Cycle project
- Only DO-254 Design lifecycle project
- Only DO-254 Verification & Validation lifecycle project
- Partial support of DO-254 Lifecycle based on customer needs
- Tool Qualification
-
For the above, following factors are considered:
- Hardware requirements (count & complexity)
- LOC count
- Customer driven testing strategies
- Customer driven process flow
- Onsite & Off-shore requirements
- Software and hardware tools and their licenses
Verilog, VHDL, MATLAB Simulink Based Design
- a. ISE 14.6, Vivado 2017.4
- b. QUARTUS Prime
- c. Actel -Libero
- a. ACTEL- Microsemi- Microchip,
- b. Xilinx, Intel- ALTERA
- c. Lattice
Multi costellation GNSS IP, AST 230 GPS-SBAS IP, Integration of Our GNSS IP into two of the customers SOC
ISO 26262 is an international functional safety standard for developing safety critical applications for electrical and/or electronic (E/E) systems that are installed in passenger cars. ISO 26262 provides automotive safety lifecycle (management, development, production, operation, service, decommissioning) guideline that helps in achieving functional safety.
CAN : Control area network is a serial communication protocol that allows multiple nodes to be connected with single CAN physical wire.
Nodes in the network can transmit and receive data bidirectional, however only one node can transmit data at any given time.
CAN protocol has two major parts i.e. Message ID and Data. The message ID will be used for transfer data from one node to another node in the network.
Node with message id with more 0s will get bus priority over the node with message id with more number of 1s.
The following are the CAN standards:Standard CAN : 11 bit message identifier, Data up to 8bytes, Speed 1 Mbit/s, CRC integrity check
Extended CAN: 29 bit message identifier, Data up to 8bytes, Speed 1 Mbit/s, CRC integrity check
CAN FD: Data up to 64bytes, Speed 12 Mbit/s, Improved CRC integrity check
CAN bus protocol specified in ISO 11898.
LIN:
Local Inter connect network is a serial communication protocol that allows 1 master and 16 slaves to be connected in a network.
LIN is mostly used for connecting sensors into a network, it supports data transfers up to 20 kbit/s.
LIN bus protocol specified in ISO 17987.
MOST:
Media Oriented Systems Transport is a serial communication protocol used in vehicles for multimedia data (Audio, Video..etc) transfer.
MOST allows up to 64 devices in a network of masters, which controls network, timing and synchronization , and slaves.
It is used in both synchronous and asynchronous communication in Infotainment domain.
Diagnostic communication protocols helps in diagnose the vehicles through OBD(on board diagnostic) port.
The common features of Diagnostic communication protocols are listed below:
The following diagnostic protocols used in Automotive industry:
Note, Heavy duty vehicles satisfy the OBD-II requirements via J1939-73 protocol.
Cars uses KWP(ISO 14230) and UDS(ISO 14229) diagnostic protocols. Both these protocols run on IS0 15765 communication protocol.