One of my Hobbies is thinking up impractical solutions for the world of problems. My point here today is, if a person’s need for social interaction is inversely related to the quality of his or her imagination, In other words, if you have an excellent imagination, you might enjoy people, but you’re equally happy to be alone with your thoughts for large stretches. To put it bluntly, you fascinate yourself.
My assumption is that people have widely different powers of imagination. This seems likely. People are all over the map for every other mental ability. Whatever is happening inside the mind of the person with the worst imagination on earth is clearly very different from what’s happening in the mind of the most creative.
Presumably, if you have no imagination whatsoever, you need to get all of your stimulation from the environment, mostly from other people. On the other end of the spectrum, if your imagination is extraordinary, interaction with other people will just get in the way of the incredible experiences you could otherwise be having entirely in your head.
Tuesday, March 24, 2009
Wednesday, March 18, 2009
OffShore.... Not Offshore... NearShore..
After interacting and meeting many different mindset people across the globe with different profiles and different age groups, I intended to share my interactions on the Globalisation.
1. I came across few people saying that offshoring is plagued with problems in effectiveness, productivity and communication, and if they could choose again between offshoring or not, they would not go through with it.
2. I came across few people saying, In every business there is always pressure to drive Development and QA costs down from the Top management and that is typically achieved by offshoring portions if not all the work to India, China or South America.
3. Few people said, offshoring work to South America is pretty easy as the managemnt oversight is very less.
4. Few people said, the competitive advantage and Technical skills brought in by the global resources is driving the businesses to expand in emerging markets like India and China which is helping the companies to grow and make bigger profits.
In all the above situations, we try and put all the necessary processes in place to manage it and keep it sane unfortunately to no avail. Reporting, communication, competency and productivity problems always arise, that make you to think, you would never gotten into offshoring......why is this happening? The offshore mangers doesn't have good insight on the projects or the Engineers are not competitive enough in following the process, standards and delivering projects on time?
It is high time for the Global resources to realise and be sensible to understand why productivity is not at par with global standards. It applies to everyone working in IT industry, to drive the quality upstream.
Every one has to realise, we have to add value to the Globalisation by offering real-time metrics and reports, clear and open communication and collaboration between onsite and offshore, and easy assignments and scheduling capabilities.
I request my Blog readers to post their comments on this article.
1. I came across few people saying that offshoring is plagued with problems in effectiveness, productivity and communication, and if they could choose again between offshoring or not, they would not go through with it.
2. I came across few people saying, In every business there is always pressure to drive Development and QA costs down from the Top management and that is typically achieved by offshoring portions if not all the work to India, China or South America.
3. Few people said, offshoring work to South America is pretty easy as the managemnt oversight is very less.
4. Few people said, the competitive advantage and Technical skills brought in by the global resources is driving the businesses to expand in emerging markets like India and China which is helping the companies to grow and make bigger profits.
In all the above situations, we try and put all the necessary processes in place to manage it and keep it sane unfortunately to no avail. Reporting, communication, competency and productivity problems always arise, that make you to think, you would never gotten into offshoring......why is this happening? The offshore mangers doesn't have good insight on the projects or the Engineers are not competitive enough in following the process, standards and delivering projects on time?
It is high time for the Global resources to realise and be sensible to understand why productivity is not at par with global standards. It applies to everyone working in IT industry, to drive the quality upstream.
Every one has to realise, we have to add value to the Globalisation by offering real-time metrics and reports, clear and open communication and collaboration between onsite and offshore, and easy assignments and scheduling capabilities.
I request my Blog readers to post their comments on this article.
Tuesday, March 17, 2009
DO-178B Standards
Lately, I am reading a book called- Avionics Certification, A Complete guide to DO-178 (Software) & DO-254 (Hardware) by Vance Hilderman and Tony Bhagai.
After going through this Book, It made me to realise and think deeper about the True costs and Benefits of following DO-178B standards for Avionics Software certification.
People who are working in Avionics doamin know that DO-178B has increasingly evolved into the de-facto standard for commercial avionics, then Military avionics, and now general aerospace electronics. And the new DO-178C is on the horizon. DO-178B requires planning, consistency, determinism, thorough documentation and testing, and proof of the preceding attributes. DO-178B relies upon testing to verify and validate avionics quality. However, avionics quality comes from a quality process followed in the projects, design, and implementation, not just testing.
The DO-178B (software) and DO-254 (hardware) standards presume that hardware and software must operate in harmonic unison, each with proven reliability. Previously, hardware was considered “visible” and tested at the system level with integrated software; hence hardware was exempt from DO-178B quality attributes. But that exemption resulted in functionality being moved from software to hardware for the purpose of avoiding hardware
certification. Also, hardware complexity has evolved such that hardware is often as complex, or more so, than software due to the embedded logic within the PLDs, ASICs and FPGAs.
In DO-178B “software” pertains to all drivers, BSP, RTOS, libraries, graphics, and the application software. In other words, any executable which is loaded into memory during execution. Software testing means ensuring that the lowest level detailed requirements are accurately implemented, paths are covered according to their criticality level, and full traceability is provided. Increasingly, tools are being used to automate DO-178B processes.
DO-178B entail five different levels of criticality, ranging from Level A (most critical) to Level E (least critical). Each avionics system is assigned one or more levels of criticality, and each component within that system must meet or exceed its assigned criticality level. As the criticality level increases, so does the degree of rigor associated with documentation, design, reviews, implementation, and verification. Accordingly, cost and schedule increase as well.
DO-178B levels are defined as Level E, Level D, Level C, Level B and Level A. Level A being the most critical software and Level E being the lowest critical software. Each level of certification has different requirements.
Level D certified software still has generally full planning, requirements, implementation, reviews, and basic testing processes applied. Plus configuration management, quality assurance, and DER liaison are applied to Level D. Yet the costs of Level D are hardly more than any non-certified commercial software process. Why? Because Level D is comprised almost entirely of normal industry-standard software engineering principals.
The cost impact of DO-178B is the most significant between Level D and Level C. Why? Level C requires the following which Level D does not and which result in Level C requiring 30% more budget and schedule than Level D:
• Testing of low-level software requirements
• Ensuring 100% coverage of all source code statements
• Greater rigor placed upon reviews
• In many cases more rigorous configuration management
Level B requires additional structural coverage (decision-condition, e.g. all branches in the source code), additional independence in reviews, and tighter configuration management. On first glance then, it would seem that Level B should be significantly more expensive, e.g. 50% - 70%, than Level C. In theory, it seems to make sense, but as in many areas of life, common sense overcomes theory. In Level B (and C) there must be detailed, low-level software requirements and they must be thoroughly tested. During requirements-based testing, most (70-90%) of the branches in the source code are already executed and hence require no additional structural coverage testing if test capture and coverage tools are appropriately used! Therefore, the seemingly significant cost increase associated with Level B versus C structural coverage is already mitigated by requirements-based testing. Also, quality software engineering organizations already incorporate a semi-automated and streamlined process which includes independent reviews and tight configuration management; hence the added cost of those aspects for Level B is largely mollified.
Level A is the most critical software level and hence the most expensive. Level A imposes yet more structural coverage requirements (MCDC testing), robustness and correlation requirements, and slightly more stringent reviews. The most significant cost driver over Level B is the MCDC testing requirement. However, with proper application of modern structural coverage tools, personnel training, and thorough requirements based testing, the added cost for Level A can be largely contained.
Benefits and Advantages of following the DO-178B standards right from the beginning of the project will be :
• Greater upfront requirements clarity. DO-178B mandates thorough and detailed software requirements. Such detail, and the necessary discipline, force answers to be provided up-front instead of being deferred. Assumptions are drastically minimized. Consistency of requirements and their testability is assured. Iterations and rework due to faulty and missing requirements are greatly reduced.
• Fewer coding iterations. Code iterations, or churn, are the bane of software engineering. In many cases, 10, 20, and even 30 versions of evolving code files exist on new products. Nonsense. Code should be largely correct the first time it is written and should not require dozens of updates to get it right. Code should be reviewed by analyzing implementation versus documented requirements.
• Fewer bugs found during unit testing. Since DO-178B mandates thorough and testability requirements, in addition to code reviews, far fewer bugs will be found during unit testing. Independent code reviews also further that aim.
• Greater consistency within software. Software is like a chain: only as strong as its weakest link. Software which is 99% correct is 1% incorrect, which means it is unsafe. The weakest software module, or software engineer, is on the critical path of software safety. All software must be consistent per its level of criticality and DO-178B enforces such.
• Fewer defects found during integration. Integration can be a lengthy iterative process where major defects requiring design changes are uncovered and fixed. Not with DO-178B, where integration is typically 50-75% faster than non-DO-178B environments.
• Improved configuration management. The ability to control and recreate any snapshot of the project is covered by Configuration Management (CM). However, CM also ensures security, backups, completed reviews, problem reporting, and version control. DO-178B’s strong CM requirements, coupled with modern tools which automate many CM tasks, ensures higher softwarequality now and in the future.
• More thorough testing.
• Easier regression testing. You build your product on the assumption that it will be successful, and therefore have a long life. You also know your software will evolve through new applications, installations, and versions. Regression testing can be expensive if extensive or manual; DO-178B provides thorough traceability to determine which modules need changes or analysis, and corresponding retesting.
• Fewer in-the-field defects. In-the-field defects and customer returns are hugely expensive in both the short and long-term. Products developed under DO-178B have been demonstrated to achieving 80%-90% fewer returns.
• Improved re-usability. Via thorough and consistent documentation required by DO-178B, modularization, enforcement of documented modern engineering principles, and reviews to ensure all the above was achieved, reusabilityis greatly improved. In software, re-usability is the Holy Grail, but thereality is that unless a software component is at least 80% re-usable (e.g. unchanged), then it is quicker and less risky to simply start from scratch. In reality, most software is less than 50% “re-usable”. With DO-178B, and enforcement of design/coding standards, coupled with independent reviews and traceability, most modules should be at least 90% re-usable.
• Improved customer satisfaction. Reliable software begets reliably returning customers.
• Decreased single-point personnel failures. Software is an art; artists resist documenting their work and subjecting it to common development standards and peer reviews. Without standards, discipline, and modern software engineering principals, software teams devolve into a group of loosely structured rogue artists; these artists are highly valuable, creative, and talented persons. However, the loss, or deficiency, of any such artist for any reason is catastrophic to the team. Unless their work is documented, understood, and consistently applied as for the other artists. DO-178B greatly reduces the possibility of such single-point personnel failures.
• Improved management awareness of true schedule status. How many oftware projects report a “99% Complete” status week after week? How is oftware progress measured? How can management truly ascertain ompletion status of software? The answer to all these questions is via odern and accurately detailed management techniques built around DO-178B. The provision for insight, traceability, accurate status on design, development, testing, integration, and reviews is found in DO-178B.
I tried to pull together few of the imp points, I understood out of this Book, which may be useful for the people working in Avionics Domain. Enjoy reading!!
After going through this Book, It made me to realise and think deeper about the True costs and Benefits of following DO-178B standards for Avionics Software certification.
People who are working in Avionics doamin know that DO-178B has increasingly evolved into the de-facto standard for commercial avionics, then Military avionics, and now general aerospace electronics. And the new DO-178C is on the horizon. DO-178B requires planning, consistency, determinism, thorough documentation and testing, and proof of the preceding attributes. DO-178B relies upon testing to verify and validate avionics quality. However, avionics quality comes from a quality process followed in the projects, design, and implementation, not just testing.
The DO-178B (software) and DO-254 (hardware) standards presume that hardware and software must operate in harmonic unison, each with proven reliability. Previously, hardware was considered “visible” and tested at the system level with integrated software; hence hardware was exempt from DO-178B quality attributes. But that exemption resulted in functionality being moved from software to hardware for the purpose of avoiding hardware
certification. Also, hardware complexity has evolved such that hardware is often as complex, or more so, than software due to the embedded logic within the PLDs, ASICs and FPGAs.
In DO-178B “software” pertains to all drivers, BSP, RTOS, libraries, graphics, and the application software. In other words, any executable which is loaded into memory during execution. Software testing means ensuring that the lowest level detailed requirements are accurately implemented, paths are covered according to their criticality level, and full traceability is provided. Increasingly, tools are being used to automate DO-178B processes.
DO-178B entail five different levels of criticality, ranging from Level A (most critical) to Level E (least critical). Each avionics system is assigned one or more levels of criticality, and each component within that system must meet or exceed its assigned criticality level. As the criticality level increases, so does the degree of rigor associated with documentation, design, reviews, implementation, and verification. Accordingly, cost and schedule increase as well.
DO-178B levels are defined as Level E, Level D, Level C, Level B and Level A. Level A being the most critical software and Level E being the lowest critical software. Each level of certification has different requirements.
Level D certified software still has generally full planning, requirements, implementation, reviews, and basic testing processes applied. Plus configuration management, quality assurance, and DER liaison are applied to Level D. Yet the costs of Level D are hardly more than any non-certified commercial software process. Why? Because Level D is comprised almost entirely of normal industry-standard software engineering principals.
The cost impact of DO-178B is the most significant between Level D and Level C. Why? Level C requires the following which Level D does not and which result in Level C requiring 30% more budget and schedule than Level D:
• Testing of low-level software requirements
• Ensuring 100% coverage of all source code statements
• Greater rigor placed upon reviews
• In many cases more rigorous configuration management
Level B requires additional structural coverage (decision-condition, e.g. all branches in the source code), additional independence in reviews, and tighter configuration management. On first glance then, it would seem that Level B should be significantly more expensive, e.g. 50% - 70%, than Level C. In theory, it seems to make sense, but as in many areas of life, common sense overcomes theory. In Level B (and C) there must be detailed, low-level software requirements and they must be thoroughly tested. During requirements-based testing, most (70-90%) of the branches in the source code are already executed and hence require no additional structural coverage testing if test capture and coverage tools are appropriately used! Therefore, the seemingly significant cost increase associated with Level B versus C structural coverage is already mitigated by requirements-based testing. Also, quality software engineering organizations already incorporate a semi-automated and streamlined process which includes independent reviews and tight configuration management; hence the added cost of those aspects for Level B is largely mollified.
Level A is the most critical software level and hence the most expensive. Level A imposes yet more structural coverage requirements (MCDC testing), robustness and correlation requirements, and slightly more stringent reviews. The most significant cost driver over Level B is the MCDC testing requirement. However, with proper application of modern structural coverage tools, personnel training, and thorough requirements based testing, the added cost for Level A can be largely contained.
Benefits and Advantages of following the DO-178B standards right from the beginning of the project will be :
• Greater upfront requirements clarity. DO-178B mandates thorough and detailed software requirements. Such detail, and the necessary discipline, force answers to be provided up-front instead of being deferred. Assumptions are drastically minimized. Consistency of requirements and their testability is assured. Iterations and rework due to faulty and missing requirements are greatly reduced.
• Fewer coding iterations. Code iterations, or churn, are the bane of software engineering. In many cases, 10, 20, and even 30 versions of evolving code files exist on new products. Nonsense. Code should be largely correct the first time it is written and should not require dozens of updates to get it right. Code should be reviewed by analyzing implementation versus documented requirements.
• Fewer bugs found during unit testing. Since DO-178B mandates thorough and testability requirements, in addition to code reviews, far fewer bugs will be found during unit testing. Independent code reviews also further that aim.
• Greater consistency within software. Software is like a chain: only as strong as its weakest link. Software which is 99% correct is 1% incorrect, which means it is unsafe. The weakest software module, or software engineer, is on the critical path of software safety. All software must be consistent per its level of criticality and DO-178B enforces such.
• Fewer defects found during integration. Integration can be a lengthy iterative process where major defects requiring design changes are uncovered and fixed. Not with DO-178B, where integration is typically 50-75% faster than non-DO-178B environments.
• Improved configuration management. The ability to control and recreate any snapshot of the project is covered by Configuration Management (CM). However, CM also ensures security, backups, completed reviews, problem reporting, and version control. DO-178B’s strong CM requirements, coupled with modern tools which automate many CM tasks, ensures higher softwarequality now and in the future.
• More thorough testing.
• Easier regression testing. You build your product on the assumption that it will be successful, and therefore have a long life. You also know your software will evolve through new applications, installations, and versions. Regression testing can be expensive if extensive or manual; DO-178B provides thorough traceability to determine which modules need changes or analysis, and corresponding retesting.
• Fewer in-the-field defects. In-the-field defects and customer returns are hugely expensive in both the short and long-term. Products developed under DO-178B have been demonstrated to achieving 80%-90% fewer returns.
• Improved re-usability. Via thorough and consistent documentation required by DO-178B, modularization, enforcement of documented modern engineering principles, and reviews to ensure all the above was achieved, reusabilityis greatly improved. In software, re-usability is the Holy Grail, but thereality is that unless a software component is at least 80% re-usable (e.g. unchanged), then it is quicker and less risky to simply start from scratch. In reality, most software is less than 50% “re-usable”. With DO-178B, and enforcement of design/coding standards, coupled with independent reviews and traceability, most modules should be at least 90% re-usable.
• Improved customer satisfaction. Reliable software begets reliably returning customers.
• Decreased single-point personnel failures. Software is an art; artists resist documenting their work and subjecting it to common development standards and peer reviews. Without standards, discipline, and modern software engineering principals, software teams devolve into a group of loosely structured rogue artists; these artists are highly valuable, creative, and talented persons. However, the loss, or deficiency, of any such artist for any reason is catastrophic to the team. Unless their work is documented, understood, and consistently applied as for the other artists. DO-178B greatly reduces the possibility of such single-point personnel failures.
• Improved management awareness of true schedule status. How many oftware projects report a “99% Complete” status week after week? How is oftware progress measured? How can management truly ascertain ompletion status of software? The answer to all these questions is via odern and accurately detailed management techniques built around DO-178B. The provision for insight, traceability, accurate status on design, development, testing, integration, and reviews is found in DO-178B.
I tried to pull together few of the imp points, I understood out of this Book, which may be useful for the people working in Avionics Domain. Enjoy reading!!
Zephyr 2.0 - Test Management Integrated with JIRA and Bugzilla
Ran into this tool and thought of letting my viewers know about this, as this is a combination of JIRA and Bugzilla features, which can save a lot of money with the features we get out of this tool instead of two.
Zephyr 2.0 features two-way integration with popular issue-tracking systems JIRA and Bugzilla via Web services. It allows interoperability with commercial, open-source or homegrown test automation tools and provides IT leaders with real-time insight into every step of the testing process.
Zephyr 2.0 provides a simple way for organizations to quickly get a handle on their in-house and outsourced testing activities as it enables IT management and testing teams to collaborate seamlessly across time zones. It's all about flexibility and is the only test management solution that provides end-to-end management of quality cycles, including department management, resource management, test case management, test execution, defect management, document management and all aspects of reporting and metrics in real time. QA teams save, time and effort, and improve productivity with Zephyr 2.0.
For the first time, IT leaders can realize the benefits of a test management platform in an easy-to-use, low-cost, Software-as-a-Service offering, rather than spend a fortune on complex installed applications. With the Zephyr KickStart program, organizations can have a deployed and functional test management system that suits their particular environment along with a trained test team in a matter of just two days.
Zephyr 2.0 features two-way integration with popular issue-tracking systems JIRA and Bugzilla via Web services. It allows interoperability with commercial, open-source or homegrown test automation tools and provides IT leaders with real-time insight into every step of the testing process.
Zephyr 2.0 provides a simple way for organizations to quickly get a handle on their in-house and outsourced testing activities as it enables IT management and testing teams to collaborate seamlessly across time zones. It's all about flexibility and is the only test management solution that provides end-to-end management of quality cycles, including department management, resource management, test case management, test execution, defect management, document management and all aspects of reporting and metrics in real time. QA teams save, time and effort, and improve productivity with Zephyr 2.0.
For the first time, IT leaders can realize the benefits of a test management platform in an easy-to-use, low-cost, Software-as-a-Service offering, rather than spend a fortune on complex installed applications. With the Zephyr KickStart program, organizations can have a deployed and functional test management system that suits their particular environment along with a trained test team in a matter of just two days.
Saturday, March 14, 2009
We realize very few times on the decisons we made
There is something bogging me down recently and I started thinking about it, It's true that we realize that the moments passed by was one of those which you will remember for all your life.. And sometimes when you look back and still find those moments there waiting for you.., the sense of righteousness slurps all over you.. Seeing that your judgement proved right, gives a sense of underlying wisdom..(which sometimes might surprise you..)
The most important discovery of self comes when we realize the power of our unconscious mind when we deeply think about few things, when you find out that the decisions you made without giving them any thought were your best ones.. That’s when the genius inside you shines at its brightest, because those are solely your decisions with no influences of any kind.
These are my feelings from the different experiences I had in my life on few of the decisions I made...
The most important discovery of self comes when we realize the power of our unconscious mind when we deeply think about few things, when you find out that the decisions you made without giving them any thought were your best ones.. That’s when the genius inside you shines at its brightest, because those are solely your decisions with no influences of any kind.
These are my feelings from the different experiences I had in my life on few of the decisions I made...
Do you need professional qualifications to be a Good Manager?
This was the question, revolving in many peoples mind in the recent past who are working in IT industries. I was reading an article from my friend Kolli on qualifications for Good Managers (who has double Masters from a reputed University at US and pursuing Phd currently).
Even when there was no education on management, we had best managers. With or without management education, they do have some wonderful traits. That made them best, and what would they be? I am inspired and picked up few points from his article. This is what he believes are the primary instintcts of the Best manager :
1. SMART: Being able to understand the difference between good and bad, truth and lie, and being able to deal with good and bad politics.
2. GOOD: Being a good person is most important for a manager. Otherwise it can affect a whole organization and many jobs.
3. STRONG: Being able to protect the team from controversies and take ground when you know your team is right.
4. PROACTIVE AND ADAPTABLE: Helps them to prevent mistakes and react fast to changes and get good from the changes. And makes them capable to use new technologies to be ahead.
5. VISION: A vision to make well defined goals, to see future trends in work and technology and use those tools to bring best helps them to bring best into task/projects they take care of.
6. HONEST and TRUSTWORTHY: Arguably this is part of good, but I find this so important that it merits being mentioned separately.
7. MISSION: Does not allow daily urgencies to deflect from the ultimate longer term goals.
8. OBSERVE and RESPECT: Listen, look, Pay attention to other people's goals, opinions and actions.
Even when there was no education on management, we had best managers. With or without management education, they do have some wonderful traits. That made them best, and what would they be? I am inspired and picked up few points from his article. This is what he believes are the primary instintcts of the Best manager :
1. SMART: Being able to understand the difference between good and bad, truth and lie, and being able to deal with good and bad politics.
2. GOOD: Being a good person is most important for a manager. Otherwise it can affect a whole organization and many jobs.
3. STRONG: Being able to protect the team from controversies and take ground when you know your team is right.
4. PROACTIVE AND ADAPTABLE: Helps them to prevent mistakes and react fast to changes and get good from the changes. And makes them capable to use new technologies to be ahead.
5. VISION: A vision to make well defined goals, to see future trends in work and technology and use those tools to bring best helps them to bring best into task/projects they take care of.
6. HONEST and TRUSTWORTHY: Arguably this is part of good, but I find this so important that it merits being mentioned separately.
7. MISSION: Does not allow daily urgencies to deflect from the ultimate longer term goals.
8. OBSERVE and RESPECT: Listen, look, Pay attention to other people's goals, opinions and actions.
Saturday, March 7, 2009
Faulty Radio Altimeter leads to Airplane Crash
First Let me explain basic functionality of Radio Altimeter keeping in view of my blog readers, and how the faulty RAdio Altimeter may leads to airplane crash, which we have seen from the recent Turkish airplane crash.
Functionality of RA: Radio Altimeter measures altitude above the terrain presently beneath an aircraft. This type of altimeter provides the distance between the plane and the ground directly below it. As the name implies, radar (radio detection and ranging) is the underpinning principle of the system. Radiowaves are transmitted towards the ground and the time it takes them to be reflected back and return to the aircraft is timed. Because speed, distance and time are all related to each other, the distance from the surface providing the reflection can be calculated as the speed of the radiowave and the time it takes to travel are known quantities.
Alternatively, the change in frequency of the wave can be measured, the greater the shift the further the distance travelled.
Radar altimeters are frequently used by commercial aircraft for approach and landing, especially in low-visibility conditions and also automatic landings, allowing the autopilot to know when to begin the flare maneuver.
Recently Dutch investigators revelead that a faulty altimeter may have led to the crash of the Turkish Airlines 737-800 that killed nine, including three of four Boeing employees on the jet and the three crew members in the cockpit. As a result of the malfunctioning altimeter, the auto pilot reduced engine power too soon, what it means is : Boeing jet was at 1,950 feet when the left altimeter indicated the aircraft was at minus 8 feet. The auto pilot (with out pilot's intervention) subsequently cut engine power before the plane reached the runway. Boeing issued a statement saying the throttles idled for 100 seconds, decreasing the airspeed to about 40 knots below what it should have been. The flight data recorder from the crashed jet showed the altimeter was giving bad information just before the plane landed on two of its last eight flights.
It is always preferable to carefully monitor the primary Flight Instruments during critical phases of each flight rather than relying on Autopilot.
Functionality of RA: Radio Altimeter measures altitude above the terrain presently beneath an aircraft. This type of altimeter provides the distance between the plane and the ground directly below it. As the name implies, radar (radio detection and ranging) is the underpinning principle of the system. Radiowaves are transmitted towards the ground and the time it takes them to be reflected back and return to the aircraft is timed. Because speed, distance and time are all related to each other, the distance from the surface providing the reflection can be calculated as the speed of the radiowave and the time it takes to travel are known quantities.
Alternatively, the change in frequency of the wave can be measured, the greater the shift the further the distance travelled.
Radar altimeters are frequently used by commercial aircraft for approach and landing, especially in low-visibility conditions and also automatic landings, allowing the autopilot to know when to begin the flare maneuver.
Recently Dutch investigators revelead that a faulty altimeter may have led to the crash of the Turkish Airlines 737-800 that killed nine, including three of four Boeing employees on the jet and the three crew members in the cockpit. As a result of the malfunctioning altimeter, the auto pilot reduced engine power too soon, what it means is : Boeing jet was at 1,950 feet when the left altimeter indicated the aircraft was at minus 8 feet. The auto pilot (with out pilot's intervention) subsequently cut engine power before the plane reached the runway. Boeing issued a statement saying the throttles idled for 100 seconds, decreasing the airspeed to about 40 knots below what it should have been. The flight data recorder from the crashed jet showed the altimeter was giving bad information just before the plane landed on two of its last eight flights.
It is always preferable to carefully monitor the primary Flight Instruments during critical phases of each flight rather than relying on Autopilot.
Subscribe to:
Comments (Atom)
