TomTom « Terug naar discussie overzicht

Over GPS positions, probes en realtime traffic

205 Posts, Pagina: « 1 2 3 4 5 6 7 8 9 10 11 » | Laatste
[verwijderd]
1
Solid state Lidar miniaturiseringg ontwikkelingen (Delphi/ Quanergy):
www.autonews.com/article/20151026/OEM...
www.autonomes-fahren.de/delphi-quaner...
(Samenwerking met o.a. Hyundai/Kia; Tom2 zit in de nieuwe Hyundai Tucson)
Ook Bosch zet hier op in:
www.autonomes-fahren.de/bosch-autonom...

Lidar voor $250 in de auto. Waarom zouden ze dat zo graag willen? (Tom2/RoadDNA)
Gijsie
0
quote:

Hik schreef op 7 november 2015 11:04:

Lidar voor $250 in de auto. Waarom zouden ze dat zo graag willen? (Tom2/RoadDNA)
In het artikel staat dat je er vier nodig hebt, maar 250 dollar is een hele redelijke prijs voor een auto-onderdeel. Pas nog twee veren laten vervangen voor 150 euro per stuk. Monteur gaf de schuld aan de verkeersdrempels. Die zijn inderdaad absurd in mijn woonwijk. Die kunnen straks ook weer weg als de software zelf mag rijden.
[verwijderd]
1
LTE Netwerk toepassing:

Interessante ontwikkeling zijn de "Cloudlets":

These cloudlets ensure that information is directly routed within the cells, instead of transporting data through the mobile network via the cloud. This means that end-to-end latency can be cut dramatically, to 20 milliseconds and below. Without the new technology, transmission of signals between two vehicles via LTE networks and the central cloud can take a hundred milliseconds in the best-case scenario, and as much as several hundred milliseconds in unfavorable conditions. Road safety applications via mobile networks are only possible thanks to this fast data transmission.

telematicswire.net/deutsche-telekom-f...

en.wikipedia.org/wiki/LTE_(telecommun...
Beperktedijkbewaking
0
Ben niet onder de indruk. De tijdwinst is iets als 0,2 sec. Vrijwel verwaarloosbaar bij menselijke reactietijden in de praktijk (ca 2 sec., het gaat niet om gespannen schaatsers bij de start).

O, het gaat om HAD en selfdriving? Wie bepaalt dat zo'n snelle hazard melding alleen voor de desbetreffende LTE cell relevant is? Het zal net zo vaak voor een aangrenzende cell relevant zijn, of zelfs voor de rest of the world, via een traffic server van ene TomTom...
Daar is dus slimme software voor nodig, in-vehicle of cellwise, om het onderscheid of de verbinding te maken (weg tijdwinst dan). Plus de nodige standaards all-over the industry...

V2V hazard alerts vereisen echt een meer functionele en technische 'architectuur' dan hier voorgespiegeld wordt.
Wie waren hier ook al weer bij betrokken? Effe kijken, oja, Nokia Networks doet ook mee, dacht ik het niet. Technisch best knap op cell-niveau, maar functioneel ondoordacht. Brave ingenieurs in de bocht.

[verwijderd]
0
quote:

Beperktedijkbewaking schreef op 13 november 2015 08:22:

Ben niet onder de indruk. De tijdwinst is iets als 0,2 sec. Vrijwel verwaarloosbaar bij menselijke reactietijden in de praktijk (ca 2 sec., het gaat niet om gespannen schaatsers bij de start).

O, het gaat om HAD en selfdriving? Wie bepaalt dat zo'n snelle hazard melding alleen voor de desbetreffende LTE cell relevant is? Het zal net zo vaak voor een aangrenzende cell relevant zijn, of zelfs voor de rest of the world, via een traffic server van ene TomTom...
Daar is dus slimme software voor nodig, in-vehicle of cellwise, om het onderscheid of de verbinding te maken (weg tijdwinst dan). Plus de nodige standaards all-over the industry...


V2V hazard alerts vereisen echt een meer functionele en technische 'architectuur' dan hier voorgespiegeld wordt.
Wie waren hier ook al weer bij betrokken? Effe kijken, oja, Nokia Networks doet ook mee, dacht ik het niet. Technisch best knap op cell-niveau, maar functioneel ondoordacht. Brave ingenieurs in de bocht.
Think twice. Dat zullen die ontwikkelaars namelijk ook doen. Als jij als ontwikkelaar weet dat "sommige" incidenten een extreem korte reactietijd vergen om levens te kunnen redden dan hoef je geen dagen te gaan zitten piekeren hoe je dat rap genoeg door je centrale server gejast krijgt. Dan ga je werken aan decentrale beslislogica die besluit welke incident afhandelingsroute gevolgd zal gaan worden bij welk type incident en ontwikkel je meerdere van die routes (zonodig aanvullend op elkaar). Als V2V- of V2I-communicatie ook reële en valide opties dan kun je die ook inzetten voor de meest optimale incident afhandeling.

Ik denk dat we dat TomTom allang niet meer hoeven uit te leggen. Die denken al zo ver vooruit dat wij alleen maar met ontzag kunnen toekijken. Alle dingen die ik bedacht heb in de afgelopen jaren van hoe dingen zouden kunnen gaan werken worden NU inderdaad zo geïmplementeerd. Parking staat al om de hoek. Virtuele groene golven zijn er binnen 2-3 jaar. Dus het zal hiermee niet anders zijn dan dat ze daar al lang mee bezig zijn.

Het zal mij benieuwen wat er nog meer uit hun IoT-brainstorm teams is gekomen wat we de komende jaren als producten/diensten terug gaan zien. Deze mensen zijn als heel kleine voorhoede van onze maatschappij de welvaart voor onze komende generaties aan het creëren, in een fantastische oud-Hollandse traditie met stevige support uit good-old Brabant, de slimste regio van de wereld, haha.
Beperktedijkbewaking
0
Dank xynix, voor je commentaar.
Je bent een aardsoptimist, ik ben meer een nuchtere analyticus. Maar de 'samenwerking' is prima, het dwingt me tot verder analyseren van de potentiële technische toekomst, voorzover ik dat nog kan natuurlijk. Ook anderen (Justin, Hik, ...) dwingen me daartoe trouwens. Daarom is dit ook zo'n boeiend forum, ondanks enkele verdwaalde gasten af en toe.
We zullen vast en zeker op deze dingen terug komen.

[verwijderd]
1
quote:

Beperktedijkbewaking schreef op 13 november 2015 08:22:

Ben niet onder de indruk. De tijdwinst is iets als 0,2 sec. Vrijwel verwaarloosbaar bij menselijke reactietijden in de praktijk (ca 2 sec., het gaat niet om gespannen schaatsers bij de start).

O, het gaat om HAD en selfdriving? Wie bepaalt dat zo'n snelle hazard melding alleen voor de desbetreffende LTE cell relevant is? Het zal net zo vaak voor een aangrenzende cell relevant zijn, of zelfs voor de rest of the world, via een traffic server van ene TomTom...
Daar is dus slimme software voor nodig, in-vehicle of cellwise, om het onderscheid of de verbinding te maken (weg tijdwinst dan). Plus de nodige standaards all-over the industry...

V2V hazard alerts vereisen echt een meer functionele en technische 'architectuur' dan hier voorgespiegeld wordt.
Wie waren hier ook al weer bij betrokken? Effe kijken, oja, Nokia Networks doet ook mee, dacht ik het niet. Technisch best knap op cell-niveau, maar functioneel ondoordacht. Brave ingenieurs in de bocht.

Dit gaat echt over Internet routing. IOT wil zeggen dat alles elkaar adresseert met IP-adressen. De router 'weet' dat jij en ik aangaande dit hazard in het zelfde IP-netwerksegment zitten en hoeft het verkeer tussen ons niet in de cloud te gooien. Ik veronderstel dat er zoals bij Quality of service (QOS), danwel DiffServ (Type Of Service) een 'tag' in de IP-header opgenomen zal zijn waardoor het netwerk intelligent kan routeren en niet alles klakkeloos over de schutting de cloud in gooit, maar voor een speciaal type berichten besluit dat er een broadcast in het zelfde segment uitgezonden wordt). Het verkeer tussen ons blijft hierdoor een lokale aangelegenheid en de latency daardoor minimaal. 3G netwerken kennen een hoge latency. Jij vindt de factor 10 verwaarloosbaar, maar stel nou dat 1 hazard uit meerdere berichten bestaat. Dan wordt het behoorlijk significanter lijkt me?
Wat vind je er eigenlijk 'functioneel ondoordacht' aan?
[verwijderd]
0
quote:

Hik schreef op 15 november 2015 22:32:

[...]
Dit gaat echt over Internet routing. IOT wil zeggen dat alles elkaar adresseert met IP-adressen. De router 'weet' dat jij en ik aangaande dit hazard in het zelfde IP-netwerksegment zitten en hoeft het verkeer tussen ons niet in de cloud te gooien. Ik veronderstel dat er zoals bij Quality of service (QOS), danwel DiffServ (Type Of Service) een 'tag' in de IP-header opgenomen zal zijn waardoor het netwerk intelligent kan routeren en niet alles klakkeloos over de schutting de cloud in gooit, maar voor een speciaal type berichten besluit dat er een broadcast in het zelfde segment uitgezonden wordt). Het verkeer tussen ons blijft hierdoor een lokale aangelegenheid en de latency daardoor minimaal. 3G netwerken kennen een hoge latency. Jij vindt de factor 10 verwaarloosbaar, maar stel nou dat 1 hazard uit meerdere berichten bestaat. Dan wordt het behoorlijk significanter lijkt me?
Wat vind je er eigenlijk 'functioneel ondoordacht' aan?
Hik, echt leuk dat jij er tegenwoordig ook bij bent in deze technische discussies. AB! Het lijkt inderdaad logisch een deel van het berichtenverkeer volgens de V2V c.q. V2I route af te wikkelen. Dan moet je alles om je heen inderdaad "snel" kunnen benaderen door rechtstreeks via jouw dichtsbijzijnde router(s) berichten direct naar de juiste IP-adressen te sturen. De Internet-structuur zorgt dan als het goed is automatisch voor de kortste weg naar die adressen. Misschien dat daar dan nog wel nieuwe mechanismen voor nodig zijn. Jij zegt volgens mij terecht dat het daarbij mogelijk om een "burst" aan berichten gaat, juist omdat het om een "hazard" gaat.

Een essentiële stap in die "high-speed" communicatie zou moeten zijn al vooraf je potentiële ge-adresseerden te kennen. Dat zou (A) langzaam, in overleg met een server, mogen die de roedel rondrijdende voertuigen kent met hun posities en dus hun nabijheid t.o.v. jouw eigen voertuig. De navigatiesoftware kan dan een dynamische lijst met IP-adressen bijhouden die zinvol benaderbaar zijn voor V2V "hazard alerting". Op die manier is deze essentiële -langzame- stap niet meer noodzakelijk wanneer het "gevaar" daadwerkelijk optreedt. Zo'n mechanisme lijkt mij overigens perfect patenteerbaar, dus wie weet zit dat ook al weer in de molen bij TomTom.

Een alternatief zou zijn (B) dat routers de mogelijkheid krijgen om op verzoek een lijst te genereren voor V2V-/V2I-communicatie. Maar dat lijkt een zeer lastige klus om voor elkaar te krijgen door vele betrokken partijen met allemaal verschillende belangen en met mogelijk erg grote privacy- en veiligheidsrisico's.

Heb jij daar een visie op, hoe je het "doel-domein" gaat beheren?
[verwijderd]
0
Interessant artikel..

Making Cars Smarter
SoCs are replacing MCUs in electronic control units as complexity rises.

semiengineering.com/making-cars-smart...
Beperktedijkbewaking
0
quote:

xynix schreef op 13 november 2015 08:37:

[...]
Think twice. Dat zullen die ontwikkelaars namelijk ook doen. Als jij als ontwikkelaar weet dat "sommige" incidenten een extreem korte reactietijd vergen om levens te kunnen redden dan hoef je geen dagen te gaan zitten piekeren hoe je dat rap genoeg door je centrale server gejast krijgt. Dan ga je werken aan decentrale beslislogica die besluit welke incident afhandelingsroute gevolgd zal gaan worden bij welk type incident en ontwikkel je meerdere van die routes (zonodig aanvullend op elkaar). Als V2V- of V2I-communicatie ook reële en valide opties dan kun je die ook inzetten voor de meest optimale incident afhandeling.

Ik denk dat we dat TomTom allang niet meer hoeven uit te leggen. Die denken al zo ver vooruit dat wij alleen maar met ontzag kunnen toekijken. Alle dingen die ik bedacht heb in de afgelopen jaren van hoe dingen zouden kunnen gaan werken worden NU inderdaad zo geïmplementeerd. Parking staat al om de hoek. Virtuele groene golven zijn er binnen 2-3 jaar. Dus het zal hiermee niet anders zijn dan dat ze daar al lang mee bezig zijn.

Het zal mij benieuwen wat er nog meer uit hun IoT-brainstorm teams is gekomen wat we de komende jaren als producten/diensten terug gaan zien. Deze mensen zijn als heel kleine voorhoede van onze maatschappij de welvaart voor onze komende generaties aan het creëren, in een fantastische oud-Hollandse traditie met stevige support uit good-old Brabant, de slimste regio van de wereld, haha.
Ga eerst een nachtje slapen, jij TomTom-ADHD-er. Met alle sympathie overigens.

Levens redden door zeg 0,10- 0,15 sec reactietijd te besparen?

Theoretisch denkbaar, maar behoorlijk onwaarschijnlijk. De menselijke reactietijd is in de praktijk 2 sec. Wat couplets extra bieden is paenuts.

OK, jij had het over boordcomputers i.p.v. mensen, over HAD en selfdriving? Die reageren sneller dan mensen, dat is waar. Zeg het maar hoeveel remweg je bij HAD wilt inbouwen...

De veilige volgtijd tussen auto's bij de huidige remsytemen is 3 sec, bij hoge snelheden. In de praktijk menen wij menselijke de automobilisten in de praktijk ons een volgtijd van 1,5-2,0 sec te kunnen permitteren. Als het mis gaat volgt dus per definitie een kettingbotsing.

Jouw en Hiks netwerkverschil van 0,1-0,2 sec zegt me niks. Het betekent hoogstens het verschil tussen wel of geen blikschade. Om mensenlevens te redden moet je meer van huis halen.

Op Hik en zijn ETSI over Mobile Edge Computing kom ik nader terug. Ik laat zijn posts daarover nu even als cliffhanger bungelen.
Maar onderschat me nooit over traffic, xynix.

[verwijderd]
0
quote:

Beperktedijkbewaking schreef op 18 november 2015 07:56:

[...]

Ga eerst een nachtje slapen, jij TomTom-ADHD-er. Met alle sympathie overigens.

Levens redden door zeg 0,10- 0,15 sec reactietijd te besparen?

Theoretisch denkbaar, maar behoorlijk onwaarschijnlijk. De menselijke reactietijd is in de praktijk 2 sec. Wat couplets extra bieden is paenuts.

OK, jij had het over boordcomputers i.p.v. mensen, over HAD en selfdriving? Die reageren sneller dan mensen, dat is waar. Zeg het maar hoeveel remweg je bij HAD wilt inbouwen...

De veilige volgtijd tussen auto's bij de huidige remsytemen is 3 sec, bij hoge snelheden. In de praktijk menen wij menselijke de automobilisten in de praktijk ons een volgtijd van 1,5-2,0 sec te kunnen permitteren. Als het mis gaat volgt dus per definitie een kettingbotsing.

Jouw en Hiks netwerkverschil van 0,1-0,2 sec zegt me niks. Het betekent hoogstens het verschil tussen wel of geen blikschade. Om mensenlevens te redden moet je meer van huis halen.

Op Hik en zijn ETSI over Mobile Edge Computing kom ik nader terug. Ik laat zijn posts daarover nu even als cliffhanger bungelen.
Maar onderschat me nooit over traffic, xynix.
Als ik eerlijk ben twijfel ik soms wel of jij nog de volle consequenties kunt overzien van de technische ontwikkelingen die gaande zijn. Vast niet t.a.v. traffic. Maar ten aanzien van IoT heb ik zo mijn twijfels. Het gaat namelijk allang niet meer over mensen en menselijke responsetijden. Het gaat om systeem/voertuig responsetijden. Ja, en dan heeft Hik een heel goed punt dat je voor bepaalde incidenten afhandelingsroutes wilt hebben die in milliseconden significant (tientallen procenten) sneller zijn.

Voor de discussie (en voor jouw eigen interesse) zou het best leuk zijn als je je meer gaat inlezen op de ontwikkelingen rond IoT. Sensoren/actuatoren en alle meuk die je tegenkomt op weg van sensor naar actuator, dat spul. Het name op een zeer belangrijk onderdeel van die "meuk", de datacommunicatie, kun je waarschijnlijk, net als ik, heel veel opsteken van Hik. En samen denken vanuit ieders sterkte is 5 keer leuker dan een wedstrijd ver plassen. En omdat je je open stelt voor nieuwe gedachten houd je er je hersenen jong mee.

Heb ik zelf afgelopen jaar meegemaakt toen mijn oudste zoon met Arduino's kwam aanzetten. Er ging een totaal nieuwe wereld voor me open en ik werd opeens weer nieuwsgierig, leergierig en creatief. In mijn nieuwe huis wil ik -puur voor de fun- via IoT technieken mijn Philips Hue lampen (gaaf!) gaan aansturen (ze gaan nu al automatisch aan als ik mij 's morgens weeg op mijn Withings weegschaal. En de tuin gaan irrigeren uit de aanwezige, werkende put op basis van sensor informatie van een zelf te bouwen "weerstation". Gewoon om te snappen welke wereld er op ons af komt.

Ver plassers zijn er al genoeg op dit forum. You don't need to be one of them.
Beperktedijkbewaking
0
quote:

Beperktedijkbewaking schreef op 18 november 2015 07:56:

[...]

...
Maar onderschat me nooit over traffic, xynix.
Jezus, wat moet ik hier nog bewijzen?

Er zijn weinigen die hier meer weten over intensiteiten en volgtijden op de diverse rijstroken... Over verwachte reistijden bij files, afhankelijk van het percentage vrachtverkeer... Er zijn weinigen die hier meer weten over metingen, of motorrijders wel of niet mee doen.

Alle kennis van TomTom, de NWB en de VID qua files op snelwegen in NL zijn van mijn hand, ook realtime. Ik bedoel, de software is van mijn hand. Ik ben de barre file-rekenkunde in de praktijk. Ook bij stilstaand verkeer. Dan weet de door mij niet alleen bedachte maar ook gerealiseerde software nog steeds hoeveel er in een file staan. En jullie couplets niet.

Ik kan beter dan het CBS onze economische verliezen door files voorspellen. Maar mijn software mocht niet van de hogere ambtenarij. No more to say.

Ik zeg al teveel. Doe ze maar de groeten, dan zal ik blij zijn.

MVG,
BDB
[verwijderd]
0
quote:

Beperktedijkbewaking schreef op 18 november 2015 09:19:

[...]
Jezus, wat moet ik hier nog bewijzen?
Voor wie, BDB? Voor wie?
Beperktedijkbewaking
0
quote:

xynix schreef op 18 november 2015 09:21:

[...]
Voor wie, BDB? Voor wie?
Voor onze maatschappij. Maar ik mocht niet van mijn ambtelijke baas. Hoe duidelijk moet ik zijn? Ik kan geen namen noemen, al zou ik het graag doen.

Lul me nooit meer over ambtelijke integriteit. De hoge bazen lullen erover, maar hebben er zelf niks mee op. Sorry hoor, dat is mijn harde oordeel.

Ik kon intellectueel en qua diploma's meer dan tegen hen op. Ook qua integriteit. Of doet dat er niet toe bij jou, xynix?

[verwijderd]
0
Aangaande de reactietijden:
Mensen reageren niet alleen trager dan sensoren, ze hebben het ook veel later door dat er iets bedreigends staat te gebeuren. Vanuit hun waarneming moeten ze via een reactie handelen. Daar gaan zoals BDB zegt 2 seconden overheen.
Connected cars werken anders. Als er iets gebeurt met een auto voor me, dan heeft deze dat zélf al gemeld. In de sensor ingestion standard is hiervoor de status "Obstacle on the Road" opgenomen.
Uit de specs:
If the vehicle detects that it is located on the road and a potential obstacle to other vehicles, this state is set.
Oftewel: Als ik vind dat ik een obstakel ben, dan meld ik dat zelf aan de cloud.
Dat kan natuurlijk ook voor V2V werkend gemaakt worden.
Als er zo'n status binnen mijn 'subcloudje' geldt, dan weet mijn boardcomputer dat al véél eerder dan ik en manouvreren we er gewoon omheen.
En dat is het verschil tussen 100% selfdriving en niet 100% selfdriving. In mijn ogen wordt het door uitschakelen van menselijke handelingstraagheid allen maar veiliger op de weg.

@Xynix, jouw eerdere vraag over even "wie zijn nu eigenlijk mijn buren en hoe bereik ik ze zonder cloud" ben ik nog even mee bezig. Daar is vast wel iets over geschreven. Maarja, tijd!
[verwijderd]
0
BDB, lees het nog eens rustig terug. De tegenvraag op jouw vraag "Wat moet ik hier nog bewijzen?" was: "(bewijzen) voor wie?"

Misschien kun je beter voor je zelf bewijzen dat je ook een leuk mens kunt zijn als het niet altijd draait om "bewijzen"? Of zeg ik nu iets verkeerds?

Ik ken heel erg intelligente, integere mensen die er geen fuck om geven of ze zich hebben "bewezen" en zichzelf juist daardoor continu bewijzen. De TomTom insider die ik dit weekend sprak is daarvan een treffend voorbeeld. Echte klasse straalt er vanzelf vanaf.

Denkstof voor bij een (één) glaasje wijn. Verder ga ik het hier bij laten, anders wordt dit weer zo "off topic". Uiteindelijk zijn posts als die van Hik zojuist boeiender.
Beperktedijkbewaking
0
quote:

Beperktedijkbewaking schreef op 18 november 2015 09:19:

[...]

...

Alle kennis van TomTom, de NWB en de VID qua files op snelwegen in NL zijn van mijn hand, ook realtime. Ik bedoel, de software is van mijn hand. Ik ben de barre file-rekenkunde in de praktijk. Ook bij stilstaand verkeer. Dan weet de door mij niet alleen bedachte maar ook gerealiseerde software nog steeds hoeveel er in een file staan. En jullie couplets niet.

Ik kan beter dan het CBS onze economische verliezen door files voorspellen. Maar mijn software mocht niet van de hogere ambtenarij. No more to say.
...

No more to say.

[verwijderd]
0
quote:

Beperktedijkbewaking schreef op 18 november 2015 13:34:

[...]

No more to say.

Als het allemaal zo "goed" is zoals u zegt waarom is het dan niet toegepast?
Dan had u het zelf de wereld in moeten slingeren.
Beperktedijkbewaking
0
quote:

Hik schreef op 18 november 2015 10:07:

Aangaande de reactietijden:
Mensen reageren niet alleen trager dan sensoren, ze hebben het ook veel later door dat er iets bedreigends staat te gebeuren. Vanuit hun waarneming moeten ze via een reactie handelen. Daar gaan zoals BDB zegt 2 seconden overheen.
Connected cars werken anders. Als er iets gebeurt met een auto voor me, dan heeft deze dat zélf al gemeld. In de sensor ingestion standard is hiervoor de status "Obstacle on the Road" opgenomen.
Uit de specs:
If the vehicle detects that it is located on the road and a potential obstacle to other vehicles, this state is set.
Oftewel: Als ik vind dat ik een obstakel ben, dan meld ik dat zelf aan de cloud.
Dat kan natuurlijk ook voor V2V werkend gemaakt worden.
Als er zo'n status binnen mijn 'subcloudje' geldt, dan weet mijn boardcomputer dat al véél eerder dan ik en manouvreren we er gewoon omheen.
En dat is het verschil tussen 100% selfdriving en niet 100% selfdriving. In mijn ogen wordt het door uitschakelen van menselijke handelingstraagheid allen maar veiliger op de weg.

@Xynix, jouw eerdere vraag over even "wie zijn nu eigenlijk mijn buren en hoe bereik ik ze zonder cloud" ben ik nog even mee bezig. Daar is vast wel iets over geschreven. Maarja, tijd!
Het is allemaal brave toekomst, my friend:

www.etsi.org/technologies-clusters/te...

Moet ik hier ook nog het ETSI white paper gaan downloaden? Allerlei invitations, en vele dwarsverbanden met allerlei LTE standaards. Maar elk verkeerskundig protocol is nog ver weg.

Niet dat dat in het nadeel van TT is, overigens. En daar gaat het dit forum toch om, nietwaar?

[verwijderd]
0
@BDB, Ik snap niet wat je wil zeggen met: "Het is allemaal brave toekomst". De toekomst is één split second vanaf nu, iedere seconde weer. Het is toch niet verkeerd om daar onze fantasie op los te laten? Ik lees herhaaldelijk dat Xynix dingen heeft 'voorspeld' die nu waarheid aan het worden zijn. Leuk toch?
Ik ben géén specialist, maar dit is voor mij gewoon een leuke gedachten exercitie en dat dan in samenhang met Tom2, zelfrijdende auto's etc.

Het is mij allemaal nog niet helemaal duidelijk hoe straks V2V communicatie gaat plaatsvinden. Ik denk dat Xynix met zijn bovenstaande veronderstelling een eindje in de buurt komt, zeker als je het cursieve gedeelte leest wat ik er even uitgelicht heb. En dat dan weer combineren met geofences?

In het door jou aangehaalde document heb je het nog steeds over de cloud en hoe je daar aan de edge mee kunt connecten.
V2V moet toch ook mogelijk zijn zonder 'grote regisseur' in the sky?
Dit ETSI-document stuurt meer in de richting waar ik het moet zoeken:
www.etsi.org/deliver/etsi_tr/103200_1...

Voor echte V2V communicatie wil je gewoon niet afhankelijk zijn van het transport netwerk vanwege mogelijke uitval van dit netwerk én natuurlijk de latency die er mee samenhangt. Daarom zit ik eigenlijk voorlopig meer in de hoek van organische netwerken te denken, mogelijk gebaseerd op IEEE 1609 WAVE (Wireless Access in Vehicular Environments).

www.patentgenius.com/patent/8266315.html
.......flexibility of the organic network.

The first node is a node transmitting content to other nodes when they request such. Such a node is further called production node.
Additionally a number of portal nodes may be defined. These are nodes that keep up a list of nodes in the network and are able to insert a node to be newly inserted into the data network. Said nodes are not of essential importance to an organic network according to the invention.
Central in the network are the consumer nodes. Said nodes are provided with software to receive content and to deliver it to other nodes requesting such independent of the source. Additionally the software may be provided with routines to test the quality of a data connection and to keep up to date with the location of a number of other nodes in the network. The consumer nodes may preferably generate content themselves as well, and in that way obtain either a part, or the entire functionality of the production nodes.
Finally so-called router nodes may be present. Such nodes do nothing else but receiving and sending on content to other nodes in the network by order of production nodes or consumer nodes........
205 Posts, Pagina: « 1 2 3 4 5 6 7 8 9 10 11 » | Laatste
Aantal posts per pagina:  20 50 100 | Omhoog ↑

Meedoen aan de discussie?

Word nu gratis lid of log in met uw e-mailadres en wachtwoord.

Direct naar Forum

Detail

Vertraagd 23 mei 2024 17:35
Koers 5,585
Verschil +0,025 (+0,45%)
Hoog 5,665
Laag 5,525
Volume 259.752
Volume gemiddeld 278.182
Volume gisteren 181.100

EU stocks, real time, by Cboe Europe Ltd.; Other, Euronext & US stocks by NYSE & Cboe BZX Exchange, 15 min. delayed
#/^ Index indications calculated real time, zie disclaimer, streaming powered by: Infront