Portada
mis comunidades
otras secciones
#6:
No sé para qué tanto dinero en investigaciones, en simulaciones intentando reproducir los acontecimientos... que le pregunten a los listos de meneame, con professor a la cabeza, que a las pocas horas ya sabían exactamente lo que había pasado, y la ESA se ahorrará todo eso.
modulo-schiaparerlli-estrello-sobre-marte-fallo-sistema/c01#c-1
modulo-schiaparerlli-estrello-sobre-marte-fallo-sistema/c01#c-1
#22:
#17 Menuda puta panda de inútiles que ni siquiera saben aterrizar a la primera un satélite experimental en Marte con una reentrada en la atmósfera del 11Kms/segundo y lo único que saben hacer es analizar detalladamente los datos enviados desde 100 Millones de kilómetros de distancia para dar una respuesta que soluciones problemas futuros.
El propio artículo deja claro la incompetencia de las marcas españolas, de hecho cita que esta misma empresa tuvo un error similar en el año 1996, hace tan sólo ¡¡¡ 20 años!!!. ¡¡¡Incompetentes!!!
¡¡¡Corrupción, Corrupción, esto solo lo solucionamos con independentismo y populismo de izquierdas !!
Seguro que la Colau, la CUP , el Otegi y sus amigos manteros hubiesen solucionado el problema de forma mucho más eficiente.
El propio artículo deja claro la incompetencia de las marcas españolas, de hecho cita que esta misma empresa tuvo un error similar en el año 1996, hace tan sólo ¡¡¡ 20 años!!!. ¡¡¡Incompetentes!!!
¡¡¡Corrupción, Corrupción, esto solo lo solucionamos con independentismo y populismo de izquierdas !!
Seguro que la Colau, la CUP , el Otegi y sus amigos manteros hubiesen solucionado el problema de forma mucho más eficiente.
#21:
#19 la responsabilidad de GMV era implementar el software siguiendo las especificaciones y los requisitos que alguien externo le había dado, como bien señala el artículo.
Sin haber leído esas especificaciones y como cubren el caso que sucedió, es imposible decir que la culpa es del desarrollador del software.
Que estar a dos kilómetros bajo tierra podría considerarse un valor válido si la sonda cayera en un cráter muy profundo y no se podía asumir nada.
Lo dicho, que habría que ver que decían los requisitos, que el implementador no puede tomar ciertas decisiones.
Sin haber leído esas especificaciones y como cubren el caso que sucedió, es imposible decir que la culpa es del desarrollador del software.
Que estar a dos kilómetros bajo tierra podría considerarse un valor válido si la sonda cayera en un cráter muy profundo y no se podía asumir nada.
Lo dicho, que habría que ver que decían los requisitos, que el implementador no puede tomar ciertas decisiones.
#19:
#12
Sinceramente. La culpa es de Gmv, la empresa española.
Primero: Cualquier sensor, sea cual sea, puede fallar en un determinado instante. Ya sea porque no ha funcionado o porque ha existido una perturbación puntual que es ajena al sistema y por tanto no controlable.
Segundo: Es responsabilidad del controlador, del software español, ser lo suficienteme robusto como para tomar decisiones "decentes" ante el fallo de uno de sus sensores. Para ello debe apoyarse en informaciones obtenidas por sus otros sensores.
Tercero: De la misma manera la empresa española debe ser capaz de detectar momentos críticos y de informar al contratista. Es decir, si Gmv detecta que el fallo de un sensor puede llevar a la catastrofe del sistema, porque la decisión a tomar se basa en una única fuente de información, es GMV la responsable de informar la detección de este punto crítico para que se tomen las medidas correspondientes.
Cuarto: Para ello GMV debería haber analizado y testeado su software chequeando la respuesta del mismo ante fallos de sus sensores en cada uno de los instantes de tiempo.
Concluyendo: GMV no detectó durante el desarrollo del software controlador ningún punto crítico (malo), no realizó las simulaciones necesarias para detectar este punto crítico(peor). O sí se hicieron y se pasó de ellas.
Como desarrollador de software veo, aparte de lo anterior, Otra cagada fundamental: Y es que un software haga caso a un sensor que le indica que está a "dos kilometros bajo tierra". Ante esa señal el controlador debería haber puesto en cuarentena la información de ese sensor, ignorarlo y no "soltarse". Es decir, parece que el software controlador no sabe detectar el mal funcionamiento de un sensor. A veces detectar un malfuncionamiento es complicado(si el sensor por ejemplo siempre mide 5km/h mas de lo normal), pero en este caso "canta" porque no son esperables alturas negativas en el regimen de funcionamiento.
Si un controlador no sabe detectar cuando un sensor está mandando señales anómalas apaga y vámonos. Porque eso quiere decir que el controlador solo va a funcionar correctamente cuando todos sus sensores están correctamente funcionando. Y sinceramente, es mucho presuponer.
Sinceramente. La culpa es de Gmv, la empresa española.
Primero: Cualquier sensor, sea cual sea, puede fallar en un determinado instante. Ya sea porque no ha funcionado o porque ha existido una perturbación puntual que es ajena al sistema y por tanto no controlable.
Segundo: Es responsabilidad del controlador, del software español, ser lo suficienteme robusto como para tomar decisiones "decentes" ante el fallo de uno de sus sensores. Para ello debe apoyarse en informaciones obtenidas por sus otros sensores.
Tercero: De la misma manera la empresa española debe ser capaz de detectar momentos críticos y de informar al contratista. Es decir, si Gmv detecta que el fallo de un sensor puede llevar a la catastrofe del sistema, porque la decisión a tomar se basa en una única fuente de información, es GMV la responsable de informar la detección de este punto crítico para que se tomen las medidas correspondientes.
Cuarto: Para ello GMV debería haber analizado y testeado su software chequeando la respuesta del mismo ante fallos de sus sensores en cada uno de los instantes de tiempo.
Concluyendo: GMV no detectó durante el desarrollo del software controlador ningún punto crítico (malo), no realizó las simulaciones necesarias para detectar este punto crítico(peor). O sí se hicieron y se pasó de ellas.
Como desarrollador de software veo, aparte de lo anterior, Otra cagada fundamental: Y es que un software haga caso a un sensor que le indica que está a "dos kilometros bajo tierra". Ante esa señal el controlador debería haber puesto en cuarentena la información de ese sensor, ignorarlo y no "soltarse". Es decir, parece que el software controlador no sabe detectar el mal funcionamiento de un sensor. A veces detectar un malfuncionamiento es complicado(si el sensor por ejemplo siempre mide 5km/h mas de lo normal), pero en este caso "canta" porque no son esperables alturas negativas en el regimen de funcionamiento.
Si un controlador no sabe detectar cuando un sensor está mandando señales anómalas apaga y vámonos. Porque eso quiere decir que el controlador solo va a funcionar correctamente cuando todos sus sensores están correctamente funcionando. Y sinceramente, es mucho presuponer.
Comentarios
No sé para qué tanto dinero en investigaciones, en simulaciones intentando reproducir los acontecimientos... que le pregunten a los listos de meneame, con professor a la cabeza, que a las pocas horas ya sabían exactamente lo que había pasado, y la ESA se ahorrará todo eso.
modulo-schiaparerlli-estrello-sobre-marte-fallo-sistema/c01#c-1
El módulo Schiaparelli se estrelló sobre Marte por...
es.gizmodo.comFelicitaciones a Daniel Marin que se acaba de estrenar en su rol de padre.
#8 Si, si, muchas felicidades y tal, aunque nos deja jodidos a los que seguimos su blog, pero lo comprendemos y...
A nadie se le ocurrio enviale un peque por correo?
#9 Esperemos que el bebé sea de los tranquilillos y le deje tiempo al padre para descansar (y así poder seguir enviciándonos con su blog, jeje).
#10 http://danielmarin.naukas.com/2016/11/21/una-nueva-vida-nuevos-tiempos-blog/
280 comentarios ya, yo no lo he puesto por evitar el postureo típoico, pero este tio es grande!!! y encima malagùita!!
Yo lo que quiero es que encuentren cura a la calvicie
Estos del Moto-GP es que van como locos...
#19 y todo esto lo sabes tú desde la barra del bar o desde el salón de tu casa.
Madre mía que nivel.
Léete el artículo, porque hay un detalle fundamental, y es que el software se realiza en función a requisitos, estos requisitos son inamovibles, alcanzando el punto de que el código llega a validarse incluso por el porcentaje de lineas que se ejecutan en función de los casos, tu estas proponiendo un software gigante y tremendamente complejo susceptible a muchísimos fallos.
Como se que no lo sabes, te informo que si un sensor falla se gestiona mediante un control de errores planificado y por tanto contando con sensores alternativos, esa es tareas del que define los requisitos, que es el unico nivel que tiene visibilidad sobre todos los aspecto, no se lo inventa el que desarrolla el software de control de tierra, esto es un satélite, no la aplicación de la tienda de tu cuñao.
Por favor, no hables de lo que no tienes ni idea, GMV es el #1 Mundial en desarrollo de software para el segmento de tierra, haciendo I+D+i del de verdad, y te puedo garantizar que es un puesto merecido y ganado a pulso.
#26 Que pena no haberte podido contestar antes precisamente por estar entregando un desarrollo de software a una empresa americana de las grandes. Eso de lo que no tengo ni idea(porque tú lo digas majete).
Me encanta como me atacas personalmente sin ni tan siquiera saber a lo que me dedico. Lo de la barra del bar te lo puedes meter por donde sabes.
Leete mi comentario, porque si te lo lees sabrás que me he leido el articulo.
¿Yo estoy proponiendo un software gigante? ¿Tremendísimamente complejo?
No. Muchacho/a. No.
Lo que estoy proponiendo, aunque veo que tu comprension lectora deja bastante que desear, es:
1) GMV debe realizar por especificaciones de contrato un control robusto. Y robusto no significa de 6,000.000 lineas de codigo sino lo suficientemente "inteligente"(lo pongo entre comillas) para no decidir que tras un segundo de caida libre ya se haya bajo tierra y cortar los motores.
2) Si un sensor falla se gestiona mediante un "control de errores planificado"(o ponga aquí cualquier otro nombre equivalente como: sistema alternativo de control, sistema de control robusto ante fallo, sistema de control ante fallo no previsto, etc). Lo sé bastante bien. Precisamente es obligacion de GMV, si te lees con una tilita mi anterior comentario, responsabilidad de GMV el desarrollo de este "sistema de control ante fallo de un sensor". Y para eso han pagado a GMV muchacho/a. Y la cagada, si te has leido el articulo, es de ordago: Este "sistema de control de errores planificado"(como lo llamais en GMV) decide que se encuentra a altura negativa tras pasar 1 segundo desde el desacople. Pedazo de "sistema de control ante fallo", eh muchacho/a.
En fin, ingenierillo de GMV, pariente de trabajador de GMV, community manager de GMV, o fanboy de GMV, o lo que quieras ser, no digo que GMV sea una mala empresa, solo que esto es una de sus cagadas.
Y conozco GMV, tanto su sucursal en Sevilla como la de Barcelona, y no como trabajador sino habiendo tenido una pareja que trabaja en ambos lados.
Un saludete y una tilita.
#32 cuando sepas como funciona el sector seguimos hablando, mientras sigas diciendo estupideces sin fundamento alguno, te dejo con tu bilis.
#33 Te repito. Trabajo en el sector.
¿Mi bilis? Aquí quien ha empezado atacando personalmente ha sido tú con el que si cuñado, barra de bar & cia.
Lo dicho te has equivocado de persona totalmente. Cierra al salir.
Resumen: cuando se abrió el paracaídas, el aterrizador sufrió un bamboleo tan extremo por causas que se desconocen, que dejó K.O al sistema de orientación del módulo, sistema de orientación de fabricación estadounidense. Esta confusión del sistema de orientación estadounidense debido al inesperado excesivo bamboleo del módulo bajo el paracaídas a su vez se tradujo en una confusión del software de control de aterrizaje, software de desarrollo español pero con algoritmos y especificaciones no españolas, que dependía del correcto funcionamiento del sistema de orientación estadounidense, así que el software español de aterrizaje intentó maniobras de aterrizaje equivocadas que al final dejaron el módulo en caída libre.
Culpable primero de la cadena de acontecimientos: el factor desconocido que causó el bamboleo tan extremo del módulo.
Culpable segundo: el sistema de orientación estadounidense que no pudo copar con todo ese bamboleo y quedó confundido.
Culpable tercero: el software de aterrizaje español, cuya operación correcta dependía de la operación correcta del sistema de orientación estadounidense, que no se estaba produciendo
Conclusión final: los españoles no somos culpables.
Adición a la conclusión final: en 1996 el Ariane 5 también explotó en el aire por culpa del software de navegación inercial, y este software no fue desarrollado por españoles.
Cuestión adicional: ¿Es toda esta historia verdad, o es solo una historia inventada para que los españoles podamos quitarnos las culpas de encima?
#12 Más que buscar culpables, lo que tratan de conseguir estas investigaciones es identificar los errores cometidos para aprender de ellos y avanzar.
Decir la nacionalidad de determinado componente es pura anécdota. Otra cosa es que hubiera un historial continuado de cagadas.
#15 De acuerdo con eso último. Pero el artículo sí menciona nacionalidades, cosa innecesaria para identificar errores.
#12
Sinceramente. La culpa es de Gmv, la empresa española.
Primero: Cualquier sensor, sea cual sea, puede fallar en un determinado instante. Ya sea porque no ha funcionado o porque ha existido una perturbación puntual que es ajena al sistema y por tanto no controlable.
Segundo: Es responsabilidad del controlador, del software español, ser lo suficienteme robusto como para tomar decisiones "decentes" ante el fallo de uno de sus sensores. Para ello debe apoyarse en informaciones obtenidas por sus otros sensores.
Tercero: De la misma manera la empresa española debe ser capaz de detectar momentos críticos y de informar al contratista. Es decir, si Gmv detecta que el fallo de un sensor puede llevar a la catastrofe del sistema, porque la decisión a tomar se basa en una única fuente de información, es GMV la responsable de informar la detección de este punto crítico para que se tomen las medidas correspondientes.
Cuarto: Para ello GMV debería haber analizado y testeado su software chequeando la respuesta del mismo ante fallos de sus sensores en cada uno de los instantes de tiempo.
Concluyendo: GMV no detectó durante el desarrollo del software controlador ningún punto crítico (malo), no realizó las simulaciones necesarias para detectar este punto crítico(peor). O sí se hicieron y se pasó de ellas.
Como desarrollador de software veo, aparte de lo anterior, Otra cagada fundamental: Y es que un software haga caso a un sensor que le indica que está a "dos kilometros bajo tierra". Ante esa señal el controlador debería haber puesto en cuarentena la información de ese sensor, ignorarlo y no "soltarse". Es decir, parece que el software controlador no sabe detectar el mal funcionamiento de un sensor. A veces detectar un malfuncionamiento es complicado(si el sensor por ejemplo siempre mide 5km/h mas de lo normal), pero en este caso "canta" porque no son esperables alturas negativas en el regimen de funcionamiento.
Si un controlador no sabe detectar cuando un sensor está mandando señales anómalas apaga y vámonos. Porque eso quiere decir que el controlador solo va a funcionar correctamente cuando todos sus sensores están correctamente funcionando. Y sinceramente, es mucho presuponer.
#19 la responsabilidad de GMV era implementar el software siguiendo las especificaciones y los requisitos que alguien externo le había dado, como bien señala el artículo.
Sin haber leído esas especificaciones y como cubren el caso que sucedió, es imposible decir que la culpa es del desarrollador del software.
Que estar a dos kilómetros bajo tierra podría considerarse un valor válido si la sonda cayera en un cráter muy profundo y no se podía asumir nada.
Lo dicho, que habría que ver que decían los requisitos, que el implementador no puede tomar ciertas decisiones.
#21 Las especificaciones y los requisitos nunca son absolutos. No es posible definir todas las especificaciones de antemano porque solo las simulaciones, una vez creado el software, es capaz de detectar casuísticas no detectadas al principio.
Pero si quieres hablamos de las especificaciones y requisitos, seguro que hablan del "diseño de un sistema de control robusto". Si llaman robusto a decidir que estaba a 2km bajo tierra tras haber pasado un segundo desde el despliegue del paracaídas entonces hay un problema evidente de concepto. Aunque lo que creo es que ha habido un fallo evidente de testeo y de falta de simulación.
#23 What? En la industria espacial, los requisitos son absolutísimos. Al contrario que en desarrollo de software convencional, en esta industria, el cliente (normalmente el equipo de una misión) sabe mucho mas que el desarrollador en cuanto a lo que el producto debe hacer o no. De ellos depende definir con precisión los requisitos del software y los límites de lo que se considera una situación normal o no.
En cuanto al testeo y simulación, la misión exomars, al igual que cualquier otra pasa por un periodo de simulación no menor a 6 meses en el que todo el equipo (entre los que se incluyen miembros del "software support") actúa como si de la misión de verdad se tratase, recreando diversas etapas de la futura misión. Durante estos ensayos, el responsable de misión se dedica a "putear" al software y a los ingenieros introduciendo fallos a drede en los datos o incluso desconectando sistemas enteros. Todo este teatrillo tiene 2 objetivos principales: Entrenar a los ingenieros a actuar en situaciones fuera de lo normal y a detectar posibles fallos en los diferentes sistemas.
Si estados no válidos no han sido detectados, la responsabilidad primera deberá recaer sobre una mala ejecución de la simulación, después sobre una mala definición de requerimientos y en última instancia sobre el software desarrollado.
#30 ¿Quien ha dicho que los requisitos no son absolutísimos? No habrás visto salir esa afirmación por mi boca
Por ninguna parte leeras que haya escrito que GMV deba saltarse algun requisito.
Es cierto que existe un periodo de simulación de al menos 6 meses donde un conjunto de responsables de cada empresa implicada mas los responsables de mision se dedican a putear al software. Y es cierto que estos testeos no han demostrado ser suficientes. Estos tests son de conjunto y analizan comportamientos interrelacionados.
Sin embargo, y como bien sabrás, antes de estos testeos de conjunto cada empresa de software involucrada está obligada a someter a cada uno de sus programas a testeos unitarios para comprobar el correcto funcionamiento del mismo.
En este caso GMV debería haber realizado un testeo de su software(que supongo habrán logicamente hecho porque su contrato así lo requiere) y deberían haber detectado en los mismos un fallo tan crítico como la caída a plomo ante un fallo de uno de los sensores. Te recuerdo que el software encargado a GMV es el que toma la decisión de cortar motores tras un fallo en un sensor.
La unica cosa con la que no estoy de acuerdo contigo es que el cliente conozca mejor los requisitos que la propia GMV. O mejor dicho, estoy absolutamente de acuerdo que los requisitos definidos por el contratista son de obligatoria aplicación, pero es obligación de GMV de comprobar que son, además, suficientes y no entran en conflicto entre ellos para crear un control lo suficientemente robusto.
Supongamos varios escenarios posibles:
1) El contratista en los diagramas de flujo, requisitos, ha definido el comportamiento de como debe actuar el control robusto ante la señal del sistema inercial pero se le olvida definir que debe hacer ante el fallo del mismo.
Cuando el programador de GMV llega al punto de programar la respuesta del controlador detecta que el contratista no le ha definido este comportamiento ante señal anómala. Supongamos que entonces GMV entiende que al no definirle un comportamiento puede implementarlo como le de la gana. Y así lo hace. Cuando llegue el momento de realizar el testeo unitario(el testeo propio de GMV) al controlador, el testeo debe ser lo suficientemente amplio(intensivo y extensivo)como para comprobar que la decisión tomada por el controlador no lleva a pegarse un "vejigazo" contra el suelo. Probablemente además, aunque depende de los controles de calidad internos de GMV, el programador haya creado un test particular, red flag, para precisamente esta situación no definida contractualmente y así asegurar que el controlador funciona, ante esta situacion, correctamente.
En este caso a GMV se le puede achacar el hecho de que su decisión ha llevado al desastre de la misión y un testeo insuficiente.
2) Supongamos que GMV al programar el controlador se da cuenta de que existe este requisito necesario que el contratista no le ha dado. GMV que no es tonta y para cubrirse las espaldas le solicita al contratista que le defina como debe comportarse el controlador ante el fallo del sensor. El contratista le define un comportamiento que debe seguir y GMV lo implementa. GMV debería señalar este suceso con una bandera roja para que al realizar el testeo este caso se testeara a conciencia al ser un cambio a posteriori(los cuales son facil de que entren en conflicto con otros criterios ya implementados). Supongamos que ni contratista ni GMV se dan cuenta pero este cambio genera un desastre. Cuando llega a la fase de testeo interno de GMV, los tests que deben ser lo suficientemente intensivos y extensivos reflejan este desastre y se solicita un nuevo comportamiento al contratista.
En este caso GMV es culpable de no realizar los suficientes tests internos para detectar requisitos incoherentes.
3) A GMV se le pasa unos requisitos correctos de como se debe comportar el controlador ante el fallo del sensor inercial pero GMV lo implementa incorrectamente. GMV es culpable de un incorrecto desarrollo.
4) A GMV se le pasa unos requisitos correctos pero uno de ellos aunque definido desde el principio es incorrecto(el comportamiento ante señal anomala inercial). En este caso GMV deberia haber creado un test para esta situación ya que viene definida en los requisitos.
En este caso GMV es culpable de no haber desarrollado este test unitario ante comportamiento anómalo.
El unico caso en el que se salva GMV es en el caso de que GMV hubiese detectado en los tests este fallo y hubiese informado al contratista, el cual decidiese ignorar esta situación.
Te pondría enlaces a criterios de calidad, unit tests, normativa de proyectos, pero creo que te las sabes
¿Sabes lo que pasa? Que muchas veces el la creacion de tests se deja para el final, que a veces por ser lo ultimo y con el tiempo apremiante no son lo suficientemente extensivos, y que a veces se pueden saltar ciertoa criterios de calidad internos.
Obviamente la pelota se lanzará entre el que desarrolló la ingeniería de detalle, los requisitos y GMV. Y en ese embrollo se quedará todo.
De todas formas algo pasa en la ESA con sus tests y las de sus contratas porque en las uñtimas misiones han habido grandes cagadas en mayusculas que sencillos tests habrían detectado. Pero eso lo dejo para otro comentario.
#35 ¿Quien ha dicho que los requisitos no son absolutísimos?
Pues tú mismo en #23:
Las especificaciones y los requisitos nunca son absolutos.
De todos modos, yo no estoy tratando de exculpar a nadie. Sólo intento que se entienda que, en caso de un fallo en el software, existe una cadena de responsabilidad que hace que la "culpa" no recaiga directamente sobre el desarrollador.
Por eso, desanimaría a cualquiera a lanzar juicios culpabilizando directamente a GMV ya que, de momento, no existen datos que respalden esa teoría.
No hagamos sensacionalismo por favor.
#36 Creo que el resto de mi comentario de donde has extraido esa frase deja bastante claro a que me refiero con ese "absoluto". Donde reflejo precisamente que GMV no solo debe seguir las "absolutas" especificaciones sino detectar ademas requisitos que no se le han entregado y actuar en consecuencia. "Absoluto" desde la acepción de "entero, total, completo" de la RAE.
Los requisitos por propia definición son "de obligado cumplimiento por algo son requisitos. Es mas por ser requisitos deben ser ademas, segun la UNE 157001:2014 (si no recuerdo mal) coherentes, no ambiguos, concisos, alcanzables y verificables.
No voy a entrar a tirar de normativa, pero esto es como en los proyectos. Si yo a un constructor le doy los planos de una casa y se me olvida en la ingenieria de detalle decirle por donde debe pasar una bajante, el constructor que necesita de ese requisito para realizar su labor es obligacion suya contactar con el proyectista para que le resuelva un requisito no definido. El contratista no coge y dice, pued ea no hay bajante. De la misma manera si un requisito es incoherente con otro, aun siendo ambos "absolutos" (una bajante que corta a una tuberia de gas) el constructor es responsable de solicitar al proyectista las correcciones necesarias.
Sinceramente, conociendo como conozco los proyectos de software (y no, no hablo de hacer una app movil, con todo mi respeto a las apps moviles), GMV no puede entregar un controlador robusto(requisito fundamental seguro en el contrato) que corte los motores tras haber pasado tan solo un segundo desde la separación. Entre otras cosas porque un requisito debe ser verificable y creo que el proceso interno de verificación de GMV no ha detectado este fallo.
Sensacionalismo es soltar rebuznos por la boca sin argumentar y creo que mis comentarios están bastante argumentados.
Sensacionalismo es extraer una frase sacandole del resto de contexto, o simplemente definir como sensacionalista una opinion que estando argumentada es contraria a la deseada.
Ya me gustaría a mí leer una opinión defendiendo a GMV mínimamente argumentada.
#37 No te lo tomes a mal hombre, que no iba yo por ahí.
Sensacionalismo para mí es sacar conclusiones sobre algo a partir de información insuficiente.
Ahora mismo, con la información liberada, para ti y para mí nos es imposible saber si realmente la culpa fue de GMV o no. Lo único que podemos hacer es especular basandonos en nuestros conocimientos y experiencia.
No tengo nada en contra de especular, pero normalmente cuando yo lo hago, suelo usar fórmulas del estilo "Seguramente...", "A lo mejor...", "Yo opino...", etc. Sin embargo, tú en #19 catégoricamente declaras que la culpa es de GMV cuando realmente no lo sabes:
"Sinceramente. La culpa es de Gmv, la empresa española."
Para mí ese comentario va más allá de la mera especulación y cae en el sensacionalismo.
#21 Te doy la razón. Sin saber las especificaciones es difícil saber dónde esta la culpa. Si resulta que en esas especificaciones no se contemplan medidas de seguridad en caso de saturación de la unidad inercial... pues no le compete a la empresa de software decidir ponerlas porque sí... no son ellos quienes van a decidir cómo tiene que aterrizar la sonda.
Aliens.
Esto me suena. Se llama pasar la bola. Ahora los desarrolladores de esta pieza dirán que no funciono porque hubo un giro muy brusco al abrir el paracaídas fuera de los limites operativos.
Luego los del paracaídas dirán que el momentos de la apertura iba muy rápido y por eso fue tan fuerte.
Luego el astrofísico dirá que el la puso donde tocaba pero la atmósfera ese día era menos densa.
Resultado, la culpa del hombre del tiempo de Marte.
#4 El mismo día que se inventaron las culpas se inventaron las disculpas.
#4 Y por eso cuando un avión se estrella no buscan culpables, porque nunca es una sola cosa, solo buscan riesgos y la mejor manera de evitarlos en el futuro.
#0 Mira a ver que a mi estas "cosas" se me escapan.
-> El módulo Schiaparelli se estrelló sobre Marte por un fallo en su sistema de navegación
El módulo Schiaparelli se estrelló sobre Marte por...
es.gizmodo.com#3 Aquí parece explicar y profundizar más, en el enlace que pones sobre el IMU (Unidad de Medición Inercial) habla de refilon (1 vez), en el artículo enviado tiene más de 15 referencias a el.
Sería mas bien relacionada.
#24 Las descalificaciones a otros usuarios no están permitidas, se consideran un abuso grave y pueden dar lugar a la cancelación de la cuenta.
https://meneame.wikispaces.com/Abusos
https://www.meneame.net/legal.php#tos
Hoy mismo hemos estado comentando unos amigos el desastre de la misión. Una pena que espero no desanime a los políticos a seguir en la línea de la exploración espacial y la investigación científica.
Está claro que los marcianos la derribaron...
Mas milllones de dolares a la mierda
Mientras tanto en la tierra seguimos avanzando hacia el fascismo y dificultando la investigación
Wrong way.
#29 Mierda, te voté negativo sin querer al ir a responder Te compenso en otro comentario.
Lo que venía a decir es que el módulo estrellado no era más que una parte pequeña de la misión, un extra casi. Schiaparelli no era más que un prototipo con una vida útil de unos pocos días (funciona con baterías únicamente, no tiene paneles solares). La misión exomars sigue adelante con su cometido principal que nos ayudará a conocer más de nuestro planeta vecino, y por extensión, de nuestro sistema solar.
Como dato, el coste total de la misión exomars (no solo Schiaparelli) es de unos 1300 millones de euros; si te parece mucho piensa que eso es lo que costaría fichar a 27 cristianos ronaldos. Se despilfarra el dinero en cosas mucho más banales que la exploración espacial y que aportan mucho menos a la humanidad
marca españa
#17 Menuda puta panda de inútiles que ni siquiera saben aterrizar a la primera un satélite experimental en Marte con una reentrada en la atmósfera del 11Kms/segundo y lo único que saben hacer es analizar detalladamente los datos enviados desde 100 Millones de kilómetros de distancia para dar una respuesta que soluciones problemas futuros.
El propio artículo deja claro la incompetencia de las marcas españolas, de hecho cita que esta misma empresa tuvo un error similar en el año 1996, hace tan sólo ¡¡¡ 20 años!!!. ¡¡¡Incompetentes!!!
¡¡¡Corrupción, Corrupción, esto solo lo solucionamos con independentismo y populismo de izquierdas !!
Seguro que la Colau, la CUP , el Otegi y sus amigos manteros hubiesen solucionado el problema de forma mucho más eficiente.
#22 ?¿ que pasa que por tener un nick en catalán tengo que ser indepe?? (a parte que no soy ni catalán)
..
Pero qué gilipollas eres colega
me la suda otegui, la cup, su puta madre y la tuya payaso...
#17 Dile a los pobres que duerman en cohetes y que coman hidrógeno.