No, GP is talking about Bobby Prince's Doom soundtrack, in which many songs were based on existing metal tracks. See this page for a comparison between his version and the originals.
Looking over what I wrote, I see that I failed to check it properly for my intended meaning - for that, I apologize. I should have said that testing the software in embedded systems is a less complicated process than testing desktop applications - with embedded systems, there are far more constraints on the chosen hardware platform, the input/output interfaces, and requisite expertise levels of the user. This doesn't mean that testing embedded systems is easy (it's not), it's just that the constraints are more rigorously defined, due to the "well-componentized" property that you describe in your response. A specification which is composed of rigorously defined constraints enable testers to tell the difference between expected normal system behavior and robust system behavior; when the space of possible inputs and outputs is large enough, testing all the possible paths through the code becomes a much more complicated process. I think it's very difficult to rigorously define all of the possible inputs/outputs of a desktop application, but that doesn't mean it's impossible - it just takes far more inventiveness and creativity to define the classes of inputs and outputs involved with human-computer interaction than it does when the interactions are computer-computer.
All of that being said, my limited experience with Chrome tells me that it was not sufficiently tested for even a cursory beta release, regardless of what the Scott McCloud comic says about how Google tests it.
I think the comparison is unwarranted - mission-critical embedded systems are orders of magnitude less complex than a web browser, which is one of the reasons they can be developed to such high levels of stability. I do software verification for the civilian aerospace industry. We have the luxury of deploying this software only on hardware we built ourselves, which is made of some of the toughest electronic components on Earth. In terms of testing advantages we can leverage before flight: 1. the software has requirements which are specified to ridiculous detail from the integrated system level on down, carefully vetted by all interested parties, and 2. They are highly deterministic, in that there are very few ways that a human can/will ever interact with the system (which is why they're called "embedded systems"). There are no keyboards or monitors for users to (mis)use. Most of the interaction the system has is with other systems just like it.
For terrestrial application, inertial navigation (mostly as a backup) is still used heavily. GPS is never the sole source for navigation data for safety-critical applications - because it was never intended to be a sole source for navigation, and it's easy to jam (it's an entirely passive signal with very low signal strength). Most modern navigation systems already use hybrid navigation, a combination of sensor sources in order to detect and minimize the errors present in the other sources. These also provide fail-safes so that the system can "coast" when one or more of its sensor sources is unavailable (this already occurs with GPS, since not all satellites are not equally visible to a receiver, especially near mountains or in canyons). While coasting, sensor errors will build up again, but they can be later corrected when the sensor signals are available again. Hybrid navigation is not limited to INS/GPS - we can add LORAN (or other radio navigation sources to the mix, as well as GALILEO when it comes on-line.
The article is concerned mostly with military GPS, which is only slightly less susceptible to jamming than civilian GPS. The main weakness of GPS wrt jamming is that it's a very low power signal, usually clocking in at -160dBw. There's a good survey of the state of GPS antijam circa 2002 here.
Thank you very much! Sometimes, I get myself confused by the words "verification", "review", and "validation" - I think I understand now what you mean by verification. It's a very compelling argument - I had not considered working out the details of the design generation in the SDP.
For the development we do, we are bound by DO-178B so we have to have some design "documentation" because there are objectives defined that require proof of compliance. The rub is that out of the 60+ objectives defined only 3 pertain to "design" (40 are for verification).
I am genuinely curious how your Agile methodology satisfies the independence criteria for design and verification for DO-178B - I believe it can be done, but it seems very tricky (And I understand if you are not able to talk about it). This is a consistent sticking point for us when considering Agile methods for design/verification. To what criticality level is an FMS largely designed? I work inertial nav mostly, so we are at Level A for almost everything.
Design diagrams and documentation is needed, but only when you are crafting a new architecture and most importantly should only be used to get a code class/package architecture or development plan (which set of design patterns are going to be used, interfaces, etc.) Once the software takes form THROW OUT THE DOCUMENTATION and use a good tool to auto generated documentation from your software. Be vigilant about refactoring. If something breaks the design don't bolt on a fix. Refactor it, then regenerate the design.
Table A-4 and A-5 of DO-178B have 6 criteria which apply to software's compliance to architecture - it seems like it would be difficult to satisfy these criteria without design artifacts created independently of the software code. I would also argue that design documentation is necessary for the longevity of a project; if it ever needs to be modified down the line, what will describe the intent of the requirements when the engineers who wrote them are not there?
Straight-up UML seems to be a bad match for most embedded systems - embedded systems tend to be built on procedural design principles, and matching them to object-oriented principles is often an exercise in frustration. Bruce Powell Douglas (Doing Hard Time, Real Time UML) seems to have the best handle on which core diagram types make sense for most of the embedded systems out there - I can't recommend his work highly enough.
There is no definitive diagram standard for the embedded systems industry - the industry is still trying things out. In my corner of aerospace, Matlab Simulink is rapidly becoming our de facto standard for low-level algorithm requirements and design, with Rhapsody UML diagrams used everywhere else.
Whatever you decide on, make sure it is a technology that will be around when you need to re-visit your code. Many legacy programs are littered with the remnants of the diagrams from the SASD movement (structured analysis, structured design) which paved the way to UML. If you need to maintain your diagram system in-house, that's fine - the only reason I see people gravitating towards UML-type diagrams is the warm fuzzy feeling that UML is a well-documented diagram system that will be understood in two decades' time.
Ionospheric interference has always been a problem with GPS signals - but military GPS uses two signals (L1 and L2) in order to isolate the total effect, which is much easier to do if you can decrypt the P-code of the L2 signal. In the efforts to make civilian GPS more robust to interference, GPS will be introducing the L5 code in satellites launched this year to address this problem.
RAIM just gives you a measure of statistical confidence in your position based on pseudorange measurements, allowing you to exclude signals from bad GPS satellites - if all of your pseudoranges are off because of ionospheric interference, you would never know that that is your error source without additional aiding (inertial and/or radio navigation) in low satellite availability areas.
Lest we forget the lessons of the Philadelphia COBOL rituals of 1987, one must defile a programming language completely, otherwise it will always return from beyond the grave.
At what point does it kick in for a normal person? IANAMB (I am not a molecular biologist), but there is a truism that the human body replaces all of its cells every seven years. I would be interested in finding out what the state of the research on this truly is.
Slashdot Mirror
I hear it will also have support for Stalfos, Keese, and Gel.
THIRD BASE!
"You forget, Peter. I was present at an undersea, unexplained mass sponge migration."
Because, as we all know, technology is circular."
No, GP is talking about Bobby Prince's Doom soundtrack, in which many songs were based on existing metal tracks. See this page for a comparison between his version and the originals.
Who are the ad wizards who came up with this one?
My cellphone (a Sanyo Sprint S1) has TTY support built-in, specifically so that it can be used by the deaf.
Looking over what I wrote, I see that I failed to check it properly for my intended meaning - for that, I apologize. I should have said that testing the software in embedded systems is a less complicated process than testing desktop applications - with embedded systems, there are far more constraints on the chosen hardware platform, the input/output interfaces, and requisite expertise levels of the user. This doesn't mean that testing embedded systems is easy (it's not), it's just that the constraints are more rigorously defined, due to the "well-componentized" property that you describe in your response. A specification which is composed of rigorously defined constraints enable testers to tell the difference between expected normal system behavior and robust system behavior; when the space of possible inputs and outputs is large enough, testing all the possible paths through the code becomes a much more complicated process. I think it's very difficult to rigorously define all of the possible inputs/outputs of a desktop application, but that doesn't mean it's impossible - it just takes far more inventiveness and creativity to define the classes of inputs and outputs involved with human-computer interaction than it does when the interactions are computer-computer.
All of that being said, my limited experience with Chrome tells me that it was not sufficiently tested for even a cursory beta release, regardless of what the Scott McCloud comic says about how Google tests it.
I think the comparison is unwarranted - mission-critical embedded systems are orders of magnitude less complex than a web browser, which is one of the reasons they can be developed to such high levels of stability. I do software verification for the civilian aerospace industry. We have the luxury of deploying this software only on hardware we built ourselves, which is made of some of the toughest electronic components on Earth. In terms of testing advantages we can leverage before flight: 1. the software has requirements which are specified to ridiculous detail from the integrated system level on down, carefully vetted by all interested parties, and 2. They are highly deterministic, in that there are very few ways that a human can/will ever interact with the system (which is why they're called "embedded systems"). There are no keyboards or monitors for users to (mis)use. Most of the interaction the system has is with other systems just like it.
I'm at work - Windows Media Player auto-loaded the Ogg codecs and played the video just fine.
3d goatse! Awesome!
After reading that sentence, I was dismayed to discover that nobody has invented bleach that can be used on one's mind.
Well, yeah! Everybody wants a rock to wind a piece of string around.
For terrestrial application, inertial navigation (mostly as a backup) is still used heavily. GPS is never the sole source for navigation data for safety-critical applications - because it was never intended to be a sole source for navigation, and it's easy to jam (it's an entirely passive signal with very low signal strength). Most modern navigation systems already use hybrid navigation, a combination of sensor sources in order to detect and minimize the errors present in the other sources. These also provide fail-safes so that the system can "coast" when one or more of its sensor sources is unavailable (this already occurs with GPS, since not all satellites are not equally visible to a receiver, especially near mountains or in canyons). While coasting, sensor errors will build up again, but they can be later corrected when the sensor signals are available again. Hybrid navigation is not limited to INS/GPS - we can add LORAN (or other radio navigation sources to the mix, as well as GALILEO when it comes on-line.
The article is concerned mostly with military GPS, which is only slightly less susceptible to jamming than civilian GPS. The main weakness of GPS wrt jamming is that it's a very low power signal, usually clocking in at -160dBw. There's a good survey of the state of GPS antijam circa 2002 here.
I think it's about half tragedy of the commons and half Prisoner's Dilemma.
Thank you very much! Sometimes, I get myself confused by the words "verification", "review", and "validation" - I think I understand now what you mean by verification. It's a very compelling argument - I had not considered working out the details of the design generation in the SDP.
I am genuinely curious how your Agile methodology satisfies the independence criteria for design and verification for DO-178B - I believe it can be done, but it seems very tricky (And I understand if you are not able to talk about it). This is a consistent sticking point for us when considering Agile methods for design/verification. To what criticality level is an FMS largely designed? I work inertial nav mostly, so we are at Level A for almost everything.
Table A-4 and A-5 of DO-178B have 6 criteria which apply to software's compliance to architecture - it seems like it would be difficult to satisfy these criteria without design artifacts created independently of the software code. I would also argue that design documentation is necessary for the longevity of a project; if it ever needs to be modified down the line, what will describe the intent of the requirements when the engineers who wrote them are not there?
Straight-up UML seems to be a bad match for most embedded systems - embedded systems tend to be built on procedural design principles, and matching them to object-oriented principles is often an exercise in frustration. Bruce Powell Douglas ( Doing Hard Time , Real Time UML ) seems to have the best handle on which core diagram types make sense for most of the embedded systems out there - I can't recommend his work highly enough.
There is no definitive diagram standard for the embedded systems industry - the industry is still trying things out. In my corner of aerospace, Matlab Simulink is rapidly becoming our de facto standard for low-level algorithm requirements and design, with Rhapsody UML diagrams used everywhere else.
Whatever you decide on, make sure it is a technology that will be around when you need to re-visit your code. Many legacy programs are littered with the remnants of the diagrams from the SASD movement (structured analysis, structured design) which paved the way to UML. If you need to maintain your diagram system in-house, that's fine - the only reason I see people gravitating towards UML-type diagrams is the warm fuzzy feeling that UML is a well-documented diagram system that will be understood in two decades' time.
Ionospheric interference has always been a problem with GPS signals - but military GPS uses two signals (L1 and L2) in order to isolate the total effect, which is much easier to do if you can decrypt the P-code of the L2 signal. In the efforts to make civilian GPS more robust to interference, GPS will be introducing the L5 code in satellites launched this year to address this problem.
RAIM just gives you a measure of statistical confidence in your position based on pseudorange measurements, allowing you to exclude signals from bad GPS satellites - if all of your pseudoranges are off because of ionospheric interference, you would never know that that is your error source without additional aiding (inertial and/or radio navigation) in low satellite availability areas.
I think the short answer is "YES".
Lest we forget the lessons of the Philadelphia COBOL rituals of 1987, one must defile a programming language completely, otherwise it will always return from beyond the grave.
Software date rape?
At what point does it kick in for a normal person? IANAMB (I am not a molecular biologist), but there is a truism that the human body replaces all of its cells every seven years. I would be interested in finding out what the state of the research on this truly is.
Cue joke about defending Earth from asteroids by batting them away with the invisible hand of the free market in 3 . . . 2 . . . 1 . . .