tag:blogger.com,1999:blog-4063450658421522356.post7644887593702521521..comments2024-03-09T04:13:55.185-06:00Comments on Open PRT specification project: 100> One Hundred and Counting ...Danhttp://www.blogger.com/profile/16303568401426087509noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-4063450658421522356.post-8041720009092620552010-09-01T23:25:17.111-05:002010-09-01T23:25:17.111-05:00Dan wrote:
"I really don't get how a &quo...Dan wrote:<br />"I really don't get how a "service" model pays for right of way, excavation, etc. How much a kilometer does it work out to?"<br /><br />I exclude this to the customer. <br /><br />It is the customer's (city, airport, private/public combo, ...) responsibility to have land usage rights. And to make the decisions on track routing.<br /><br />Once the land rights are there and the routing has been shown to be good (enough) by simulations, the PRT company will "drop in" their service to the assigned area.<br /><br />This model keeps the PRT company away from local disputes on land usage. They can be nasty, and time taking. Better do business somewhere else.<br /><br />Some areas (s.a. China) don't really have much disputes. People are simply commanded to move out. With PRT, they won't have to since people can live, walk, bicycle and sleep underneath the track. It's only us westerners who put such immense focus on land ownership.<br /><br />In practise, getting an effective, modern transport system in one's neighbourhood hikes up real estate prices. e2-series.com mentioned four times hike as an example (connected to the Portland, OR tram system). They should love and welcome PRT to their neighbourhood, but initially land usage will be an issue. Communities should deal with that themselves. They already have means to do so.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-60075178100238414912010-08-31T23:52:10.545-05:002010-08-31T23:52:10.545-05:00Interesting reading, guys.
Thanks for that feed li...Interesting reading, guys.<br />Thanks for that feed link Andrew- wish they would refer the reader to which post the comments refer to.<br /><br />akuappi, Ryan, I'd like here more specifics. Akuappi, I really don't get how a "service" model pays for right of way, excavation, etc. How much a kilometer does it work out to? <br />Ryan, I see 3 systems here, in vehicle, zonal, and the whole ticketing routing thing. That doesn't seem easier than 2 to me...Then each needs backup and to be integrated with the others. Would a zone controlled system ever be able to achieve advanced functions like platooning? And if so, are you thinking that these 3 systems will still be interesting enough projects to be "open sourced?"Danhttps://www.blogger.com/profile/16303568401426087509noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-53186762561976173962010-08-31T20:26:36.579-05:002010-08-31T20:26:36.579-05:00I'd be happy enough with the Linux model but h...I'd be happy enough with the Linux model but have my doubts about whether you'd find the right group of people to write that software. Unlike Linux they don't really get the chance to use it themselves. Also, they you'd need to do a lot more than just write the software, you'd have to put it through all kinds of hoops to satisfy legal requirements (including probably lobbying to make sure those requirements are clearly stated).<br /><br />The equivalent of the Apple model in PRT would cover hardware and software. I think that's a losing game. I abhor the Apple model in the computer world. They have some good designers, but their business model, for consumers, is the worst one possible. If Apple had the market share of Microsoft, the world would be a much more dysfunctional place. Luckily, that business model, at least in the realm of operating systems, has a very hard time rising to the top, and seems most capable of some quick land grabs and holding a 5% niche.<br /><br />The Microsoft model might fit well, but I'd be betting more on the late game UNIX model. In the UNIX model there were many separate proprietary implementations. They all had rather high price tags. They were generally very good at certain things, but did a very poor job of adapting to change quickly and bringing in new partners. <br /><br />The high prices were a downside, but that mostly originated from the lack of scale since most of the volume went to DOS/Windows. The real Achilles heel was that for a software developer to create an application for UNIX he either had to do it for just one or do all kinds of crazy junk (plus testing.. don't forget the testing) on all 12 flavors. That made it very expensive to be a UNIX software vendor (low volume or high costs), so quite predictably there were far more Windows software developers, and since user's kind of buy computers and operating systems to run software...<br /><br />But here in the PRT world, the need to evolve will be somewhat muted, the costs of control systems relative to the rest of the system will be trivial, and the need for really solid, but compatible implementations will be higher.Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-56785658086944361602010-08-31T20:26:11.567-05:002010-08-31T20:26:11.567-05:00There's really two big pieces here that fit in...There's really two big pieces here that fit into that discussion of business model. One is the control software/communication. The second is the track. With any standard for those two, the other design components tend to be more independent as long as they meet the requirements of the track and control systems.<br /><br />These are different beasts and deserve different business models. <br /><br />Track really needs some standards. Track will be a bulk commodity, much of the cost of which will involve installation. You really don't want market fragmentation.. that will drive up costs, and costs are very important here.<br /><br />It is important to fully explore all the different possible designs. That may mean a few incompatible implementations, but it's important that a final choice is made.. at least on the continental level before you end up with some really ugly incompatibilities. I think this site is doing great things to help encourage the emergence of such a standard.<br /><br />It's tempting to compare the control software to an operating system, but it's really not. Sure once the R&D is done it can be reproduced at very low costs. There's some installation costs, and some maintenance/monitoring, but compared to the ratios involved with physical infrastructure like track, it's very small. This definitely naturally encourages a limited number of implementations. Track doesn't have that same natural encouragement because while there are huge downsides to many different track designs, those costs are on the back-end rather than front-end. As a result it's totally feasible to think that some gross mistake could be made in the track area if we aren't careful.<br /><br />But while the control software will trend toward very few implementations naturally, it's dissimilar from a operating system in that there isn't an unending area of feature expansion. Once control software meets the most basic requirements, there are only so many ways left to improve. It won't need to enable new applications each year, the main application will stay constant for it's entire lifetime.<br /><br />...Continued...Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-1434338754447948072010-08-31T01:21:32.091-05:002010-08-31T01:21:32.091-05:00Good points, Ryan.
My info tells that China would...Good points, Ryan.<br /><br />My info tells that China would be on the forefront of making autonomous (I mean: driving themselves) car transport in certain small cities. No manual driving would be allowed there (which simplifies the situation by orders of magnitude).<br /><br />The distributed control model suits perfectly for such a case. Vehicles on roads are inherently multi-vendor, much more than PRTs on tracks.<br /><br />I see PRT as a service, or a system. In that scenario changing from one deliverer to another would (simply) mean removing the system and building a new one. That sounds like a lot of work but if deals are 10+ years and the system is designed to be removed / altered / expanded, it's not really a problem.<br /><br />So I'm for the "Apple" way of making business here. In order to guarantee smooth integration of everything, the system should come from one source.<br /><br />I may be wrong.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-55582846180368643172010-08-31T00:37:30.323-05:002010-08-31T00:37:30.323-05:00On the topic of vendor dependency, I think that...On the topic of vendor dependency, I think that's a great thing to avoid, but you're going about it in what I suspect is the wrong way.<br /><br />Lets say you have a bunch of independent vehicles. How do they communicate? Well they have to have a protocol. In addition to make decisions they need a set of rules about which decision is made. If they don't all respect the same rules there are conflicts and failures.<br /><br />These protocols can be open or closed. If they are closed then you have a vendor dependency. If they are open, then you don't. In reality, effective open standards are usually far more than the written documentation. Almost all are represented by some actual implementation which becomes the defacto standard. At one point Internet Explorer represented the defacto HTML standard. Today it's a little more confusing, I think most designers don't consider IE the standard, but rather Firefox or Chrome. Sure there is an "official" HTML spec but that's more a theory guiding future evolution of the browsers than what people creating websites care about.<br /><br />If by chance, that is the type of system you're trying to create, take another look. It's extremely complex and breaks all the time. That's marginally okay for browsers where they're trying to make trade-off gaining evolution speed while accepting many other undesirable side-effects, but it will not work for PRT control.<br /><br />The way to insure a non-vendor dependent implementation of PRT control is through an open implementation.. i.e a full working piece of software.<br /><br />Now you could have a system where this piece of software is installed in every vehicle manufactured, but that seems difficult to me. I'm sure a standard will emerge, but choosing it ahead of time requires a level of cooperation uncharacteristic of manufacturers.<br /><br />I think your best bet is to have the simplest means of communication between the vehicles, and then create an open implementation of the central controllers (call them zone controllers if you like for familiarity, but I'm flexible on how they interact). Once you have that software and a communication protocol, then it's easy to replace any proprietary piece filling that role.Ryan Bakerhttps://www.blogger.com/profile/10358323841471401980noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-3382279081400138142010-08-26T17:25:41.295-05:002010-08-26T17:25:41.295-05:00Here's the link to the feed:
http://openprtsp...Here's the link to the feed:<br /><br />http://openprtspecs.blogspot.com/feeds/comments/defaultAndrew Fnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-21811014507155911462010-08-26T17:21:33.138-05:002010-08-26T17:21:33.138-05:00Dan, I use google reader to monitor an RSS feed of...Dan, I use google reader to monitor an RSS feed of comments from this blog. Not sure if blogger allows simple rss feeds to be shown in a sidebar. If so, there's your recent comment widget.Andrew Fnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-24348303109356782612010-08-26T16:32:16.359-05:002010-08-26T16:32:16.359-05:00Dan the Blogger Responds:
It has never been my pu...Dan the Blogger Responds: <br />It has never been my purpose to host a weekly column or a special interest blog. I am a lot more interested in how useful this body of work will be to future developers of actual systems. Having to figure out something to write about each week is a distraction from my ongoing design work, work on the SMART standards, and the general exploration of how the technological advancements of the last decade might affect PRT in general. Having publishing deadlines will only result in a lot of useless fluff and lost productivity. <br /> <br />I do value your comments a lot. They bring a lot of perspective to the issues. I only hope I can eventually get a “recent comments” widget to work again, to point people to threads that are reawakening. I also plan to put in a table of contents with descriptions of what each post is about, so that the site is easier to use as a reference. After all, the stuff we debate here is the same stuff that any future PRT designers will debate. Let’s help them get it right. Quality over quantity!Danhttps://www.blogger.com/profile/16303568401426087509noreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-7944934487173085562010-08-25T09:04:38.408-05:002010-08-25T09:04:38.408-05:00StackExchange seems to be boiling a soup of anythi...StackExchange seems to be boiling a soup of anything-under-the-sun question/answer forums.<br /><br />There's one for Public Transportation, already opened.<br /><br />http://area51.stackexchange.com/proposals/10323/public-transportation?referrer=eY7ZsQthRAh8tp9xEMVoYg2<br /><br />I think it's actually better to join forces in such a more generic group than bring one on prt itself. Then again, "PRT design" could better be handled in a group of its own.<br /><br />I joined.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-46692802454980471332010-08-24T15:51:34.068-05:002010-08-24T15:51:34.068-05:00Forum would certainly be nice but I'm a bit do...Forum would certainly be nice but I'm a bit doubtful even that would work. PRT is very opinionated area and there is no one single "truth" to be found.<br /><br />The best community site that comes to my mind is www.stackoverflow.com . Content is gathered around questions (issues) and there may be millions of those. They don't even try to link the issues together into a network - this is where wikis imho always fall short.<br /><br />It's like Google search marries Wikipedia. And it is fast, useful, and FUN.<br /><br />How about trying out stackoverflow for PRT? They do allow such licensing of the technology.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-67501628224750126172010-08-24T15:05:56.726-05:002010-08-24T15:05:56.726-05:00Hey Dan,
Maybe if you are looking to lesson your ...Hey Dan,<br /><br />Maybe if you are looking to lesson your load in terms of generating content, it might make sense to transition to more of a forum format than a blog. Create a new post every now and then on the blog as the mood and inspiration strikes you, and lock comments here and link to a forum thread with that topic for discussion. Discussions with recent comments float to the top and tend to keep going and evolving rather than die off as they fall off the page. It also lets other people create topics, which further reduces the need for you to generate content.Andrew Fnoreply@blogger.comtag:blogger.com,1999:blog-4063450658421522356.post-41657695556383376752010-08-23T04:28:13.305-05:002010-08-23T04:28:13.305-05:00Thanks, Dan.
<<
Perhaps the traditional def...Thanks, Dan.<br /><br /><<<br />Perhaps the traditional definitions of PRT control (synchronous, asynchronous) have outlived their usefulness, since virtually all systems are hybrids between the two. More useful would be to analyze how the control responsibilities are divided and shared in terms of network structure(s).<br /><<<br /><br />As a computer guy, I agree with this. I never really grasped the use of those terms, anyways.Anonymousnoreply@blogger.com