rayos cosmicos desprograman....... o los programadores son malisimos ?

[gustavopic]

hola, les comparto este tema: ( si lo ven mejor para un foro distinto , pues pasenlo )

primero me puse a pensar: que curioso, una cosa mas para saber, es mas, dice ahi que los mismos fabricantes  lo hacen , es  REAL ESTO °!!!!
bueno, hasta ahi, bueno... pero:

1 >>> el programa para votar en un pais, estoy mas que seguro que la empresa debe cobrar FORTUNA  por ese programa y como lo diseñan ??  ??  un contador ?? es en serio ?? sumo 1 a el registro y chau ??
de veras ??
sin protocolso de seguridad ??
sin registros de los ultimos 10 votos y confirmacion de que la cuenta se de  de a uno ??? que no haya "UN SALTO"! , no pensando en un rayo cosmico, si pensando en un vivo corrupto....
pero de veras cobran fortuna por un sistema de votacion , para un pais y diseñan el programa tan "a lo novato" que no es capaz de detectar la anomalia ???

2  >>>> el tema ese de el avion : de veras ???
si un programa detecta una situacion anomala  PELIGROSA directamente se tira a ejecutar la rutina ??
sin verificar varias veces las entradas de sensores ??
de veras ??
es como si el que programa eso fuese un novato total.

yo no soy un gran programador, programe PIC y cop8 en asm y arduino, poco , la verdad, en mi trabajo no  da para cosas complejas, pero si razono y tengo idea de conceptos.
no voy a verificar un pulsador preguntando "if bit" y chau, y menso si es para luego ejecutar una rutina de algo riesgoso:
se lo que es rebotes en pulsadores, tiempos de demora, que pueda quedar pegado, ruidos... en fin...

yo no se si me confundo en este tema, pero a ustedes les parece razonable esos casos que cuenta esta historia , se supone fueron reales.

[elreypic2]

Que tal gustavopic,

En definitiva es totalmente razonable lo que se enciona en este video.
YO me dedico al diseño de circuito integrados y el problema básicamente se presenta a nivel silicio, no es que el hardware o software pudieran tener errores, lo que pasa es que simplemente una partícula atraviesa el silicio con el que se forman los transistores y entonces alteran el estado de estos, de encendido a apagado. Eso no se puede corregir simplemente como tú lo piensas, es mucho más complejo que eso. De ahí que por ejemplo existan diferentes encapsulados para los circuitos integrados. Como circuitos integrados con grado comercial, industrial, automotriz, militar y el aeroespacial. No es lo mismo tener un procesador, o memoria que se va a usar en un juguete que el que se va a usar en un avión o transbordador espacial.
Precisamente al descubrir estos famosos rayos cósmicos, se hace circuito que puedan resistir tales situaciones en ambientes así y obviamente no vas a gastar billones de dólares para usar en un sistema resistente a rayos cósmico para un conteo votos. Ya de por sí las campañas políticas son costosas. Jejejeje.

Elreypic.

[DominusDRR]

Ya era algo bastante conocido. Los microcontroladores de alta gama ya poseen métodos para intentar corregir esos posibles errores, ya que son muy poco frecuentes.

Y respecto al programar se debe usar métodos como CRC para transmitir, recibir, almacenar y recuperar información.

[DominusDRR]

.

[DominusDRR]

.

[gustavopic]

hola, yo pregunto desde el punto de vista de el programador, o de el diseñador de circuitos.
si quiero hacer un circuito que me prenda o apague una lampara, pues nada >>>> salida = 1 y que prenda y chau.

ahora, si me piden un control de una luz UV o de calor, para mantener caliente a un bebe, pues ahi hare por lo menos varios sistemas:
el encendido de el rele ( una vez lo hice asi ) : sera solo y solo si una salida = 1 y la otra =0  o sea el rele esta controlado  por un NPN que da masa y por un PNP  que da + .
o si quisiera ser mas incha, y si vale la pena:
uno deba saturarse y otro abrirse para que active.( asi prevengo que un problema que me ponga todo en corto deje prendido el rele )
ademas de un circuito secundario totalmente independiente..

a eso voy:

uno puede :
( lo mas rata) : solo el programa que haga lo justo
mejor >>> ms programa para verificar las acciones delicadas en ejecucion o a ejecutarse.
mejor aun >>>  precauciones en el mismo hard de la placa
incluyendo supervision y alarma en caso de  algo incompatible.
y mas aun >>>> sistema totalmente independiente de supervision.

en los 2 casos que vi , en ese video , daba la impresion de que el programa era estilo "rata" .

cada quien hace "lo que puede "  , en lo suyo, o no hace nada.
yo no digo blindar un micro, pero si gastarse un poquito  en el diseño , para prevenir  algunas cosas.. segun el caso.

ustedes, por ejemplo: si les piden hacer un control para la puerta de un horno de microondas gigante, industrial.. hacen lo justo ?? o toman precauciones ?? si alguna persona que da adentro, si justo se corta la luz cuando esta funcionando o no... si pudiese  haber alguien adentro , si se quema o falla algo , si esto o aquello.
todo para evitar a como de lugar un accidente.
se gastan un tiempo en pensar esas situaciones y como prevenirlas ??
o nada ??

en fin, a eso iba.

por que lña electronica , a nivel de el que solo programa o diseña si da para hacer "mas " que lo justo.

[gustavopic]

.

hola amigo, te pido por favor una cosita:
la proxima vez , si estas frente a un enlace asi , fijate si con el mouse lo podes marcar y copiar el texto , y asi lo pegas aca.
no como imagen.
sabes que pasa ???
no me manejo con ingles.
y tampoco soy muy bueno con algunas cosas de la PC.
yo trate de copiarlo al texto para meterlo en un traductor, pero asi como imagen no me lo permite.

mil gracias.
y tambien gracias por compartir siempre , te leo seguido .

un abrazo. 

[remi04]

.

hola amigo, te pido por favor una cosita:
la proxima vez , si estas frente a un enlace asi , fijate si con el mouse lo podes marcar y copiar el texto , y asi lo pegas aca.
no como imagen.
sabes que pasa ???
no me manejo con ingles.
y tampoco soy muy bueno con algunas cosas de la PC.
yo trate de copiarlo al texto para meterlo en un traductor, pero asi como imagen no me lo permite.

mil gracias.
y tambien gracias por compartir siempre , te leo seguido .

un abrazo.

 


  Aprovecho que el iPhone reconoce el texto de las imágenes y permite seleccionarlo, copiar, pegar etc. Te lo dejo yo copiado y pegado en texto:

  A number of software methods can then be employed to prevent even the most remote
posibility that a program bug or the proverbial cosmic ray might trigger the write
routine. Here are some suggestions:
Avoid reading and especially updating the SE content right after power-up.
Allow a few milliseconds for the power supply to stabilize (this will be heavily
application dependent).
Add a software write-enable flag, and demand that the calling application set the
flag before calling the write routine, possibly after verifying some application-
specific entry condition.
Add a stack-level counter; each function in the stack of calls implemented by the
library should increment the counter upon entry and decrement it on exit. The
write routine should refuse to perform if the counter is not at the expected level.
Some users refuse to use the SEE memory locations corresponding to the
first address (Ox0000) and/or the last address (Oxffff), believing they could be
statistically more likely to be subject to corruption.
More seriously, store two copies of each essential piece of data, performing two
separate calls to the write routine. If each copy contains a checksum or, simply by
comparison, when reading it back, it will be easy to identify a memory corruption
problem and possibly recover.

[DominusDRR]

hola, yo pregunto desde el punto de vista de el programador, o de el diseñador de circuitos.
si quiero hacer un circuito que me prenda o apague una lampara, pues nada >>>> salida = 1 y que prenda y chau.

ahora, si me piden un control de una luz UV o de calor, para mantener caliente a un bebe, pues ahi hare por lo menos varios sistemas:
el encendido de el rele ( una vez lo hice asi ) : sera solo y solo si una salida = 1 y la otra =0  o sea el rele esta controlado  por un NPN que da masa y por un PNP  que da + .
o si quisiera ser mas incha, y si vale la pena:
uno deba saturarse y otro abrirse para que active.( asi prevengo que un problema que me ponga todo en corto deje prendido el rele )
ademas de un circuito secundario totalmente independiente..

a eso voy:

uno puede :
( lo mas rata) : solo el programa que haga lo justo
mejor >>> ms programa para verificar las acciones delicadas en ejecucion o a ejecutarse.
mejor aun >>>  precauciones en el mismo hard de la placa
incluyendo supervision y alarma en caso de  algo incompatible.
y mas aun >>>> sistema totalmente independiente de supervision.

en los 2 casos que vi , en ese video , daba la impresion de que el programa era estilo "rata" .

cada quien hace "lo que puede "  , en lo suyo, o no hace nada.
yo no digo blindar un micro, pero si gastarse un poquito  en el diseño , para prevenir  algunas cosas.. segun el caso.

ustedes, por ejemplo: si les piden hacer un control para la puerta de un horno de microondas gigante, industrial.. hacen lo justo ?? o toman precauciones ?? si alguna persona que da adentro, si justo se corta la luz cuando esta funcionando o no... si pudiese  haber alguien adentro , si se quema o falla algo , si esto o aquello.
todo para evitar a como de lugar un accidente.
se gastan un tiempo en pensar esas situaciones y como prevenirlas ??
o nada ??

en fin, a eso iba.

por que lña electronica , a nivel de el que solo programa o diseña si da para hacer "mas " que lo justo.

Ok, si esa era la idea original del post, era que lo especifiques inicialmente.

Respecto a todo lo que mencionas se denomina Sistemas en Tiempo Real y es obviamente aplicable a sistemas embebidos, ahí unos videos muy útiles para entender esos conceptos:

[DominusDRR]

.

hola amigo, te pido por favor una cosita:
la proxima vez , si estas frente a un enlace asi , fijate si con el mouse lo podes marcar y copiar el texto , y asi lo pegas aca.
no como imagen.
sabes que pasa ???
no me manejo con ingles.
y tampoco soy muy bueno con algunas cosas de la PC.
yo trate de copiarlo al texto para meterlo en un traductor, pero asi como imagen no me lo permite.

mil gracias.
y tambien gracias por compartir siempre , te leo seguido .

un abrazo.

La idea era compartir la imagen, y como no se puede compartir un archivo sin texto, añadí un punto, no era ninguna mala intención.

Un consejo, si vas deseas aprender muchas cosas relacionadas con la tecnología, mucha de la información o donde debes consultar es en Inglés. En español hay muy poco, y muchas cosas son muy básicas.

Así que es un limitante no tener conocimientos de esa lengua. Es sólo un consejo, ojalá no lo tomes muy personal.

Ya copio y pego la información que puse de las imágenes que compartí antes. (Espero que no esté protegido contra copia de texto el documento)

[DominusDRR]

Texto de primera imagen.

Tips & Tricks
 Some embedded applications are designed to run their main loops for months or years
in a row without ever being turned off or receiving a reset command. But the control
registers of a microcontroller are simple RAM memory cells. The probability that a
power supply fluctuation (un-detected by the brown-out reset circuit), an electromagnetic
pulse emitted by some noisy equipment in the proximity, or even a cosmic ray could alter
their contents is a small but finite number. Given enough time (years) and depending
on the application, you might see it happen. When you design applications that have
to operate reliably on huge time scales, you should start seriously considering the need
to provide a periodic “ refresh ” of the most important control registers of the essential
peripherals used by the application.
 Group the sequence of initialization instructions in one or more functions. Call the
functions once at power-up, before entering the main loop, but also make sure that inside
the main loop the initialization functions are called when idling and no other critical task
is pending, so that every control register is reinitialized periodically.

Texto de segunda imagen:

Tips & Tricks
 If you store important data in an external nonvolatile memory (SEE), you might want
to put some additional safety measures in place (both hardware and software). From a
hardware perspective, make sure that:
● Adequate power supply decoupling (capacitor) is provided close to the device.
● A pull-up resistor (10 k Ohm) is provided on the Chip Select line, to avoid
floating during the microcontroller power-up and reset.

● An additional pull-down resistor (10 k Ohm) can be provided on the SCK clock
line to avoid clocking of the peripheral during power-up, when the PIC32 I/Os
might be floating (tri-state).
● Verify clean and fast power-up and down slopes are provided to the
microcontroller to guarantee reliable Power-On Reset (POR) operation.
If necessary, add an external voltage supervisor (see MCP809 devices for
example).
 A number of software methods can then be employed to prevent even the most remote
possibility that a program bug or the proverbial cosmic ray might trigger the write
routine. Here are some suggestions:
● Avoid reading and especially updating the SEE content right after power-up.
Allow a few milliseconds for the power supply to stabilize (this will be heavily
application dependent).
● Add a software write-enable flag, and demand that the calling application set the
flag before calling the write routine, possibly after verifying some applicationspecific entry condition.
● Add a stack-level counter; each function in the stack of calls implemented by the
library should increment the counter upon entry and decrement it on exit. The
write routine should refuse to perform if the counter is not at the expected level.
● Some users refuse to use the SEE memory locations corresponding to the
first address (0x0000) and/or the last address (0xffff), believing they could be
statistically more likely to be subject to corruption.
● More seriously, store two copies of each essential piece of data, performing two
separate calls to the write routine. If each copy contains a checksum or, simply by
comparison, when reading it back, it will be easy to identify a memory corruption
problem and possibly recover.

[Picuino]

Como comentan en el video, se pueden usar ordenadores redundantes. Si uno falla el otro se hace cargo de los cálculos.
En PC no lo conozco, pero en PLC sí.